MySQL手册版本 5.0.20-MySQL同步(五) （4）

    来源：MySQL手册版本 5.0.20    作者：译者：叶金荣

6.10 同步疑难解答

如果按照上述步骤设定好同步之后，它不能正常工作的话，首先检查以下内容：

查看一下错入日志信息。不少用户都在这方面做得不够好以至于浪费时间。

master是否在记录二进制日志？用 SHOW MASTER STATUS 检查一下状态。如果是，Position 的值不为零；否则，确定master上使用了 log-bin 和 server-id 选项。

slave是否运行着？运行 SHOW SLAVE STATUS 语句检查

Slave_IO_Running 和 Slave_SQL_Running 的值是否都是。如果不是，确定是否用同步参数启动slave服务器了。

如果slave正在运行，它是否建立了到master的连接？运行

SHOW PROCESSLIST 语句检查I/O和SQL线程的 State 字段值。详情请看"6.3 Replication Implementation Details"。如果I/O线程状态为 Connecting to master，就检查一下master上同步用户的权限是否正确，master的主机名，DNS设置，master是否确实正在运行着，以及slave是否可连接到master，等等。

如果slave以前运行着，但是现在停止了，原因通常是一些语句在master上能成功但在slave上却失败了。如果salve已经取得了master的全部快照，并且除了slave线程之外不会修改他的数据，那么应该不会发生这样的情形。如果确实发生了，那么可能是一个bug或者你碰到了"6.7 Replication Features and Known Problems"中提到的同步限制之一。如果是一个bug，那么请按照"6.11 Reporting Replication Bugs"的说明报告它。

如果一个语句在master上成功了，但是在slave上却失败了，并且这时不能做一次完整的数据库再同步(也就是删除slave上的数据，重新拷贝master的快照)，那么试一下：

判断slave的数据表是否和master的不一样。试着找到怎么会发生这种情况，然后将slave的表同步成和master一样之后运行 START SLAVE。

如果上述步骤不生效或者没有执行，试着这个语句是否能被手工安全地运行(如果有必要)，然后忽略master的下一个语句。

如果决定要忽略master的下一个语句，只需在slave上提交以下语句：

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;

mysql> START SLAVE;如果下一个语句没有使用 AUTO_INCREMENT 或 LAST_INSERT_ID()，那么 n 的值应为为 1。否则，它的值为 2。设定为 2 是因为 AUTO_INCREMENT 或 LAST_INSERT_ID() 在master的二进制日志中占用了2条日志。

如果确定slave精确地同步master了，并且没有除了slave线程之外的对数据表的更新操作，则推断这是因为bug产生的差异。如果是使用最近的版本，请报告这个问题，如果使用的是旧版本，试着升级一下。

6.11 报告同步Bugs

当确定没有包含用户的错误，并且同步还是不能正常工作或者不稳定，就可以报告bug了。我们需要你尽量多的跟踪bug的信息。请花点时间和努力准备一个好的bug报告。

如果有一个演示bug的可重现测试案例的话，请进入我们的bug数据库。如果碰到一个幽灵般的问题(不可重现)，请按照如下步骤：

确定没有包含用户错误。例如，在slave线程以外更新slave的数据，那么数据就会不能保持同步，也可能会导致违反更新时的唯一键问题。这是外部干涉导致同步失败的问题。

使用 --log-slave-updates 和 --log-bin 选项启动slave。这会导致slave将从master读取的更新操作写到自己的二进制日志中。

在重设同步状态之前保存所有的证据。如果我们没有任何信息或者只有粗略的信息，这将很难或者不可能追查到这个问题。需要收集以下证据：

master上的所有二进制日志

slave上的所有二进制日志

发现问题时，在master上执行 SHOW MASTER STATUS 的结果

发现问题时，在master上执行 SHOW SLAVE STATUS 的结果

记录master和slave的错误日志

用 mysqlbinlog 来检查二进制日志。例如，用以下方法有助于找到有问题的查询：

shell> mysqlbinlog -j pos_from_slave_status \

/path/to/log_from_slave_status | head

一旦收集好了问题的证据，首先将它隔离到一个独立的测试系统上。然后在我们的bug数据库上进可能详细地报告问题。