前言
當我們搭建MySQL集群時，自然需要完成數據庫的主從同步來保證數據一致性。而主從同步的方式也分很多種，一主多從、鏈式主從、多主多從，根據你的需要來進行設置。但只要你需要主從同步，就一定要注意server-id的配置，否則會出現主從復制異常。
在控制數據庫數據復制和日志管理中，有兩個重要的配置：server-id和server-uuid，他們會影響二進制日志文件記錄和全局事務標識。
server-id配置
當你使用主從拓撲時，一定要對所有MySQL實例都分別指定一個獨特的互不相同的server-id。默認值為0，當server-id=0時，對于主機來說依然會記錄二進制日志，但會拒絕所有的從機連接；對于從機來說則會拒絕連接其它實例。
MySQL實例的server-id是一個全局變量，可以直接查看：
mysql> show variables like '%server_id%';+---------------+-----------+| Variable_name | Value |+---------------+-----------+| server_id | 171562767 |+---------------+-----------+1 row in set (0.00 sec)
我們可以在線直接修改全局變量server-id，但不會立即生效，所以修改后記得重啟服務。而重啟后又會重新讀取系統配置文件配置，導致剛才的修改失效，因此建議修改配置文件后重啟服務而不是在線修改：
#my.cnf[mysqld]#replicationlog-bin=mysql-binserver-id=171562767sync_binlog=1binlog-ignore-db=mysqlbinlog-ignore-db=information_schema
server-id用途
server-id用于標識數據庫實例，防止在鏈式主從、多主多從拓撲中導致SQL語句的無限循環：
我們用兩個例子來說明server-id為什么不要重復：
當主庫和備庫server-id重復時
由于默認情況replicate-same-server-id=0，因此備庫會跳過所有主庫同步的數據，導致主從數據的不一致。
當兩個備庫server-id重復時
會導致從庫跟主庫的連接時斷時連，產生大量異常。根據MySQL的設計，主庫和從庫通過事件機制進行連接和同步，當新的連接到來時，如果發現server-id相同，主庫會斷開之前的連接并重新注冊新連接。當A庫連接上主庫時，此時B庫連接到來，會斷開A庫連接，A庫再進行重連，周而復始導致大量異常信息。
生成server-id的規則
既然server-id不能相同，而當我們有10個實例時，怎么保證每個都不同呢？有幾種常用的方法：
上面的這些方法都可以，但是注意不要超過了最大值2^32-1，同時值最好>2。我采用的方法是IP地址后兩位+本機MySQL實例序號，但如果是通過docker來進行管理多實例時，這個怎么生成大家可以想下有沒有什么優美的解決方案。
server-uuid配置
MySQL服務會自動創建并生成server-uuid配置：
shell> cat ~/mysql/data/auto.cnf[auto]server-uuid=fd5d03bc-cfde-11e9-ae59-48d539355108
這個auto.cnf配置風格類似于my.cnf，但這個文件只包含一個auto配置塊和一行server-uuid配置。它是自動創建的，因此不要修改它的內容。
在主從拓撲中，主從可以知道互相的UUID，在主機上使用show slave hosts，在從機上使用show slave status查看Master_UUID字段。
server-uuid參數并不能取代server-id，他們有不同的作用。當主從同步時如果主從實例的server-uuid相同會報錯退出，不過我們可以通過設置replicate-same-server-id=1來避免報錯（不推薦）。
參考資料
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對武林網的支持。
新聞熱點
疑難解答
