bin 增強 客戶 art com .cn src == timestamp

mysql-學習-10-20170531-復制類型的選擇

遇到從庫延遲，怎麽定位是一個大事務呢 ？ 從庫延遲，你會怎麽做？ 首先 show slave status\G; 裏面有個 exec_master_log_position 裏面的數字卡主了，不會動，那麽1 通過mysqlbinlog 有2個線程 io_thread, sql_thread second_behind_master = IO_Thread.timestamp -SQL_Thread.timestamp MySQL 每秒1萬個Insert 是非常輕松的
second_behind_master = 0

S1, S2, S3 他們誰同步的最靠前，怎麽判斷 ？？？ gtid沒有上面的second_behind_master 這個參數 首先要判斷它身是不是把IO_thread拉過來的日誌執行完畢了。 read_master_log_file==relay_master_log_file
read_master_log_pos = exec_master_log_pos
recivie_gtid, execute_gtid

再看誰執行的靠前？

先看是否差一個文件否？

s1.read_master_log_file s2. read_master_log_file

再看下面的位置是否一致？

s1.read_master_log_pos == s2.read_master_pos

建議配置 為row格式+gtid

要求從庫的IO_thread給主庫一個Ack響應
對binlog日誌傳輸的保障

在金融環境： 如果使用半同步，就在設置中設置成，不允行從半同步切換到異步

PXC 是 同步復制原理的

【冒泡】 A608-李魏良-成都(673529096) 21:45:27
MySQL 5.7 半同步增強，增加 rpl_semi_sync_master_wait_slave_count 參數控制主庫接收多少個slave 寫事務成功反饋 才返回 成功給客戶端
【管理員】吳炳錫(82565387) 21:46:08
rpl_semi_sync_master_wait_for_slave_count
默認是1

mysqlbinlog + semi-sync
row+gtid

【管理員】吳炳錫(82565387) 22:21:36
master_log_file=‘mysql-bin.000100‘, master_log_pos=10000000
但是主庫上還有一個： mysql-bin.000101
【管理員】吳炳錫(82565387) 22:23:02
mysqlbinlog —start-position=10000000 mysql-bin.000100 |mysql -h s1 -P xxx -pxxxx -uxxxx
【活躍】A475-陳濤-蘇州(20548079) 22:23:17
執行兩次
【管理員】吳炳錫(82565387) 22:23:17
mysqlbinlog mysql-bin.000101 |mysql -h s1 -P xxx -pxxxx -uxxxx
mysqlbinlog mysql-bin.000101 mysql-bin.000102 |mysql -h s1 -P xxx -pxxxx -uxxxx

mysql-學習-10-20170531-復制類型的選擇