半同步複製主要是為了考慮和解決主從資料一致性的問題,5.5-5.6版本出現的這個功能,然後在5.7版本以後因為出現了mgr複製,就完全的被mgr進行代替了,現在主要是跟mgr進行對比的。
半同步複製和普通主從的說明
1、普通主從:主庫dump_thread傳送給io_thread資料,io接收到資料寫入快取以後馬上就返回ack了,不來管你後面是否落到磁碟(relaylog),所以萬一傳到快取就宕機了,就會造成主從資料不一致的問題。
2、半同步複製:當dump_thread傳送給io_thread資料時,io_thread會把資料寫入記憶體,並且當資料寫入磁碟以後才會返回給dump_thread相應的ack包,告訴dump接收完成了,否則dump_thread會阻塞,主庫必須要等到ack返回,這個ack接收是由主庫的receiver_thread進行接收的,並且告訴主庫,從庫接收到資料了,然後再接著後面的資料傳輸,是當資料庫開啟半同步複製以後生成,跟tcp/ip的ack不是同一樣東西。
現在的話這種技術已經差不多被mgr進行代替了,過段時間會出mgr(mysql group replication)的實現和配置內容。
複製過濾主要是為了來解決主從複製的時候,主庫中各種不同庫往從庫複製單個庫或者多個庫的一種功能,例:主庫中有abcd4個庫,分別要往3個從庫中複製,從庫1只複製a庫,從庫2只複製b庫,從庫3只複製c庫,這種主從複製就是複製過濾的一種。
binlog_do_db binlog白名單,如果開啟,在白名單裡的庫才進行生成binlog
binlog_ignore_db binlog黑名單,在這個列表裡的庫不生成binlog
從庫:
replicate_do_db: 白名單表示複製的庫
replicate_ignore_db: 黑名單表示不複製的庫
replicate_do_table: 白名單裡為複製的表
replicate_ignore_table: 黑名單裡為不複製的表
replicate_wild_do_table: 白名單模糊複製表
replicate_wild_ignore_table:黑名單模糊不複製表
相關配置
從庫中配置:
vim /opt/mysql-
replication
/mysql3330/my.cnf
replicate_do_db=test 只匹配小寫,所以首字母都需要小寫
systemctl restart mysqld3330
進到從庫
replicate_do_db: test
這一列就表示test加入白名單,在主庫中只複製test的binlog操作
主庫中做以下操作:
create
database test charset utf8mb4;
create
database test2 charset utf8mb4;
[(none)
]>
show
databases;+
--------------------+
|database|+
--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| test |
| test2 |
+--------------------+
6rows
inset
(0.00 sec)
在從庫中看的到現象:
[(none)
]>
show
databases;+
--------------------+
|database|+
--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| test |
+--------------------+
5rows
inset
(0.00 sec)
這個就是複製過濾的其中之一,也是複製過濾的乙個小實驗! MySQL半同步複製
1 從mysql5.5開始,mysql以外掛程式的形式支援半同步複製。如何理解半同步呢?首先我們來看看非同步,全同步的概念 非同步複製 asynchronous replication mysql預設的複製即是非同步的,主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端,並不關心從庫是否已經接收...
mysql非同步複製 半同步複製 組複製
sorce不管replica的死活,寫進binlog後,commit完成就算成功。如果最後乙個event沒有發給replica,主庫就掛了,那麼就會有丟失資料的風險。通過官方的半同步外掛程式,將binlog寫完後,傳送給replica,當replica寫入到relay log後,在主庫commit。...
MySQL主從複製 半同步複製原理
在mysql5.5之前的版本中,mysql的複製是非同步複製,主庫和從庫的資料之間存在一定的延遲,比如網路故障等各種原因,這樣子容易存在隱患就是 當在主庫寫入乙個事務成功後並提交了,但是由於從庫延遲沒有及時得到主庫推送的binlog日誌時,或者主庫突然宕機了,那麼此時從庫就可能損失這個事務,從而造成...