use*_*864 3 mysql replication logs mysql-5.1
我在 ubuntu 机器上运行了 mysql-5.1.41 master-master 设置，下面是 master 的配置：
skip-host-cache
skip-name-resolve
event_scheduler = ON
max_connections = 500
max_connect_errors = 1000
server-id = 10
replicate-same-server-id = 0
auto-increment-increment = 10
auto-increment-offset = 1
master-host = 192.168.1.106
master-user = repli
master-password = secret
master-connect-retry = 60
binlog-format = MIXED
binlog-ignore-db = information_schema
binlog-ignore-db = lb1
log-bin = /var/log/mysql/mysql-bin
log-bin-index = /var/log/mysql/bin-log.index
log-slave-updates
report-host = 192.168.1.105
replicate-ignore-db = information_schema
replicate-ignore-db = lb2
relay-log = /var/log/mysql/relay.log
relay-log-index = /var/log/mysql/relay-log.index
日志文件似乎每天都在增长。有谁知道我应该在上面的配置中包含什么参数来自动删除/刷新旧的不必要的日志，并具有适当的值，不会损坏同步？。
要轮换超过 7 天的日志，请将其添加到 my.cnf
[mysqld]
expire-logs-days=7
然后重启mysql。
要手动执行此操作，请运行以下命令：
mysql> PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 7 DAY) + INTERVAL 0 SECOND;
这会将二进制日志清除回 7 天前的午夜。
不要从操作系统级别擦除二进制日志，因为它会干扰 mysqld 旋转二进制日志的内部功能。
确保您没有清除复制正在使用的二进制日志。
这是一个如何安全地手动删除二进制日志的示例...
对于主-主设置 M1 和 M2
转到 M2 并运行以下命令：
mysql> SHOW SLAVE STATUS\G
您将看到两行显示二进制日志名称
Master_Log_File 表示上次在 M2 上读取的 M1 上的当前二进制日志。
Relay_Master_Log_File 表示上次在 M2 上执行的 M1 上的当前二进制日志。
让我们假设 M2 有这个：
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.64.176.205
Master_User: replicant
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000131
Read_Master_Log_Pos: 570079419
Relay_Log_File: relay-bin.003496
Relay_Log_Pos: 251
Relay_Master_Log_File: mysql-bin.000131
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 570079419
Relay_Log_Space: 545
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)
mysql>
在 M2，Relay_Master_Log_File说mysql-bin.000131。所以在 M1 上，你可以运行这个：
mysql> PURGE BINARY LOGS TO 'mysql-bin.000131';
既然 Master_Log_File 和 Relay_Master_Log_File 是一样的，为什么不使用 Master_Log_File 呢？
当 SQL 线程的 M2 中发生 SQL 错误时，复制将停止处理来自中继日志的 SQL。IO 线程继续从 M1 下载新的 SQL 条目并附加到 M2 的中继日志。
如果出现查询，例如UPDATE更新表中的每一行，则需要 5 分钟。在这 5 分钟内，IO 线程继续从 M1 下载新的 SQL 条目并附加到 M2 的中继日志。
鉴于这两个原因，在某些情况下Relay_Master_Log_File和Master_Log_File是不同的。在这种情况下，请始终使用Relay_Master_Log_File. 鉴于此，还有另一个原因：
很少有网络传输不良会产生损坏的中继日志的情况。当你这样做时SHOW SLAVE STATUS\G，一条错误消息将解释二进制日志可能已损坏。您应该使用中继日志启动 firstsdt。
要清除它们并从新设置开始，请执行SHOW SLAVE STATUS\G，获取Relay_Master_Log_File（RMLF），Exec_Master_Log_Pos（EMLP），然后在 M2 上运行它
STOP SLAVE;
CHANGE MASTER TO master_log_file='RMLF',master_log_pos=EMLP;
START SLAVE;
该CHANGE MASTER TO命令会清除所有中继日志并从头开始下载。
一旦您START SLAVE;再次收到损坏的错误日志消息，则网络传输不是问题。毕竟，M1 上的二进制日志可能只是损坏了。
您必须转到 M1，复制可疑日志，mysqlbinlog针对复制的二进制日志运行并重定向到文本文件。读取文本文件。如果文本文件包含胡言乱语或无法辨别的字符，那么您必须执行从站的完全同步。