我在2台Debian服务器上设置了master-master复制，它们复制了一切，包括mysql数据库本身（以便新用户等也可以复制）。 这通常工作得很好，除了大多数（如果不是全部的话）apt升级包括mysql数据库模式的一些改变，这会导致复制错误，停止复制。 最终，我总是需要通过跳过每一边的错误语句来手动修复。 这总是很耗时间，我担心我可以手动进行错误（跳过太多的语句，忘记CHANGE MASTER细节等等）。
有什么我可以做的，以确保将来的apt-get更新将得到顺利处理，而不会导致复制问题？ 当然，这有一个行之有效的最佳实践？
我不知道它是否适用于每种可能的升级scheme，但是我只是testing了这一点，升级没有任何复制问题：
# /etc/mysql/conf.d/binlog_ignoredb_mysql.cnf.disabled # Rename this to end in .cnf prior to performing `apt-get upgrade`. # Otherwise, its attempts to `ALTER TABLE users` will cause replication errors. # After upgrade is complete, rename back to .disabled and then /etc/init.d/mysql restart [mysqld] binlog-ignore-db=mysql
请注意，我的testing是在一个小的升级（5.5.41到5.5.43）。
这将是很好的知道什么命令打破了你的复制，但我想，mysql_upgrade脚本将是stream氓。 如果是的话，你可以重buildmysql包，在post安装脚本中添加一个–skip-write-binlog（5.6.7之后不需要）
但通常情况下，我永远不会只升级一台正在生产的服务器，停止从服务器，升级服务器并重新连接它们。 这是禅宗的方式。