我正在运行于 MacOS 的 16 GB RAM MySQL 上恢复 26GB mysql 转储文件。
首先我尝试像这样恢复 mysql 备份
mysql -ufoo -pbar foo < foo.dump
这导致 mySQL 崩溃,因为 foo.dump 包含许多非常有趣的国际字符,而上述命令没有处理编码。
所以我尝试了
mysql -uroot -p --default-character-set=utf8 foo
mysql> SET names 'utf8'
mysql> SOURCE foo.dump
这很有效,并且恢复过程没有崩溃,因为我猜测有趣的国际字符被正确处理了。
但是现在恢复过程非常慢。对于 26 GB 的文件,它要运行一整夜(罪魁祸首是一个包含 4000 万行的表)。我可以看到它每 15 秒恢复大约 3000 行。但是按照这个速度,恢复过程将需要很长时间。
那么有没有办法可以快速恢复转储文件并且不弄乱编码?
答案1
由于I/O
SQL 操作的磁盘活动繁重,您的进程很慢。您需要优化 innodb 以进行密集操作。修改您的 mysql 配置文件以包含以下行:
innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_buffer_pool_size:这个参数表示数据库缓冲池的大小。InnoDB 缓存表和索引数据的内存区域。当表数据缓存在 InnoDB 缓冲池中时,查询可以重复访问它,而无需任何磁盘 I/O。数据更改会被缓存,而不是立即写入磁盘。
缓冲池越大,需要的磁盘 I/O 就越少,因此可以多次访问同一张表的数据。在专用数据库服务器上,您可以将缓冲池大小设置为计算机物理内存的 80%,否则使用50 to 75
系统内存的百分比。默认缓冲池大小为 128MB
innodb_log_buffer_size:该参数表示日志缓冲区的大小。InnoDB 用于写入磁盘上的日志文件的缓冲区的大小(以字节为单位)。
较大的日志缓冲区使大型事务能够运行,而无需在事务提交之前将日志写入磁盘。因此,如果您有更新、插入或删除多行的事务,则增大日志缓冲区可以节省磁盘 I/O。
innodb_log_file_size(日志文件大小):日志组中每个日志文件的大小(以字节为单位)。较大的大小可确保服务器能够平滑工作负载活动的高峰和低谷,这通常意味着有足够的重做日志空间来处理超过一小时的写入活动。值越大,缓冲池中所需的检查点刷新活动就越少,从而节省磁盘 I/O
Innodb_write_io_线程:InnoDB 中用于写入操作的 I/O 线程数。默认值为 4。InnoDB 使用后台线程来处理各种类型的 I/O 请求。您可以使用 innodb_read_io_threads 和 innodb_write_io_threads 配置参数来配置处理数据页上的读取和写入 I/O 的后台线程数。
这些参数分别表示用于读取和写入请求的后台线程数。每个后台线程最多可以处理 256 个待处理的 I/O 请求。