主从同步设置的重要参数log_slave_updates
說明：最近部署了mysql的集群環境，詳細如下M01和M02為主主復制，M01和R01為主從復制；在測試的過程中發現了以下問題：
1、M01和M02的主主復制是沒有問題的（從M01寫入數據能同步到M02，從M02寫入數據能夠同步到M01);
2、主從同步的時候，當從M01寫入的時候，數據可以寫入到R01；
3、當從M02寫入的時候，數據就不能寫入到R01；
?
問題的原因：log_slave_updates參數的狀態為NO
mysql的官網說明如下：
| Normally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log. For this option to have any effect, the slave must also be started with the --log-bin option to enable binary logging. Prior to MySQL 5.5, the server would not start when using the --log-slave-updates option without also starting the server with the --log-bin option, and would fail with an error; in MySQL 5.5, only a warning is generated. (Bug #44663) --log-slave-updates is used when you want to chain replication servers. For example, you might want to set up replication servers using this arrangement: A -> B -> C ? ? Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. You must start both A and B with --log-bin to enable binary logging, and B with the --log-slave-updates option so that updates received from A are logged by B to its binary log.? |
a) M01同步從M02同步數據過來的時候，log_slave_updates參數用來控制M01是否把所有的操作寫入到binary log，默認的情況下mysql是關閉的;
b) R01數據的更新需要通過讀取到M01的binary log才能進行更新，這個時候M01是沒有寫binary log的，所以當數據從M02寫入的時候，R01也就沒有更新了。。
?
問題的解決方法：
?
log_slave_updates：默認值為OFF;
Dynamic Variable：NO
?
處理方法：修改/etc/my.cnf，增加一行log_slave_updates=1，重啟數據庫后就可以了；
?
總結：設置完該參數后，數據庫的架構就可以設置成M01和M02為主主同步，R01通過M01進行主從同步；
應用的寫操作中M02上面進行，讀操作中R01上面進行（如果讀操作很多的話，可以在M01上面架設多臺只讀數據庫），當M02發生故障后，系統的寫操作自動遷移到M01上面。這種架構基本可以保證大部分公司的應用需求；
總結
以上是生活随笔為你收集整理的主从同步设置的重要参数log_slave_updates的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MySQL锁阻塞分析
- 下一篇： MongoDB Driver：使用正确的