當咱們搭建MySQL
集羣時,天然須要完成數據庫的主從同步來保證數據一致性。而主從同步的方式也分不少種,一主多從、鏈式主從、多主多從,根據你的須要來進行設置。但只要你須要主從同步,就必定要注意server-id
的配置,不然會出現主從複製異常。html
在控制數據庫數據複製和日誌管理中,有兩個重要的配置:server-id
和server-uuid
,他們會影響二進制日誌文件記錄和全局事務標識。mysql
server-id
配置
當你使用主從拓撲時,必定要對全部MySQL
實例都分別指定一個獨特的互不相同的server-id
。默認值爲0
,當server-id=0
時,對於主機來講依然會記錄二進制日誌,但會拒絕全部的從機鏈接;對於從機來講則會拒絕鏈接其它實例。sql
MySQL
實例的server-id
是一個全局變量,能夠直接查看:docker
mysql> show variables like '%server_id%'; +---------------+-----------+ | Variable_name | Value | +---------------+-----------+ | server_id | 171562767 | +---------------+-----------+ 1 row in set (0.00 sec)
咱們能夠在線直接修改全局變量server-id
,但不會當即生效,因此修改後記得重啓服務。而重啓後又會從新讀取系統配置文件配置,致使剛纔的修改失效,所以建議修改配置文件後重啓服務而不是在線修改:shell
#my.cnf [mysqld] #replication log-bin=mysql-bin server-id=171562767 sync_binlog=1 binlog-ignore-db=mysql binlog-ignore-db=information_schema
server-id
用途server-id
用於標識數據庫實例,防止在鏈式主從、多主多從拓撲中致使SQL
語句的無限循環:數據庫
binlog event
的源實例binlog
,當發現server-id
相同時,跳過該event
執行,避免無限循環執行。replicate-same-server-id=1
,則執行全部event
,但有可能致使無限循環執行SQL
語句。咱們用兩個例子來講明server-id
爲何不要重複:ui
server-id
重複時因爲默認狀況replicate-same-server-id=0
,所以備庫會跳過全部主庫同步的數據,致使主從數據的不一致。spa
server-id
重複時會致使從庫跟主庫的鏈接時斷時連,產生大量異常。根據MySQL
的設計,主庫和從庫經過事件機制進行鏈接和同步,當新的鏈接到來時,若是發現server-id
相同,主庫會斷開以前的鏈接並從新註冊新鏈接。當A
庫鏈接上主庫時,此時B
庫鏈接到來,會斷開A
庫鏈接,A
庫再進行重連,周而復始致使大量異常信息。設計
server-id
的規則既然server-id
不能相同,而當咱們有10
個實例時,怎麼保證每一個都不一樣呢?有幾種經常使用的方法:3d
IP
地址+端口ID
上面的這些方法均可以,可是注意不要超過了最大值2^32-1
,同時值最好>2
。我採用的方法是IP
地址後兩位+本機MySQL
實例序號,但若是是經過docker
來進行管理多實例時,這個怎麼生成你們能夠想下有沒有什麼優美的解決方案。
server-uuid
配置
MySQL
服務會自動建立並生成server-uuid
配置:
${data_dir}/auto.cnf
文件中的UUID
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
來避免報錯(不推薦)。