我需要设置复制
所以为此我从主服务器备份并导入从服务器,现在从服务器有 20 GB 可用空间,当时我正在恢复备份主服务器有 5+ GB 的数据
之后我启用了复制
现在的问题是,在将中继日志中的数据写入从属设备时,会生成许多新的中继日志,而我在从属设备上没有空间......
启用了中继日志清除 ,但是从中继日志到数据库的写入过程非常慢...
我需要设置复制
所以为此我从主服务器备份并导入从服务器,现在从服务器有 20 GB 可用空间,当时我正在恢复备份主服务器有 5+ GB 的数据
之后我启用了复制
现在的问题是,在将中继日志中的数据写入从属设备时,会生成许多新的中继日志,而我在从属设备上没有空间......
启用了中继日志清除 ,但是从中继日志到数据库的写入过程非常慢...
通过将 binlog 格式切换为“ROW”,您可能会获得性能优势。在混合格式中,mysql正在编写基于binlog语句(从站必须重新解析和重新规划策略)并且仅在某些情况下切换到行格式(http://dev.mysql.com/doc/refman/5.1/en/binary -log-mixed.html)。
它可以即时完成:
SET GLOBAL binlog_format = 'ROW';
使用基于 ROW 的复制,您可以卸载从属服务器,这使它们更容易跟上主服务器。唯一的缺点是您可能有更大的日志文件,但是从这个“获得 5+ GB 的数据”中,我假设您主要执行插入操作,因此不会有任何区别。
最好是尝试一下,看看它的表现如何。
直到复制赶上其他选项,以将从站上的 innodb_flush_log_at_trx_commit 更改为 2。只做临时的。
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
Try adding this to your config
relay-log-space-limit=5G
当您收到更少的磁盘空间警报(达到 90%)时,只需关闭从属 io 线程
mysql> stop slave io_thread;
并在一段时间后重新启动它
mysql> start slave io_thread;
在生产中,这是唯一可能的最佳选择......