Mysql slave跳過一些更新
我有一個現有的 Mysql 5.1.73 Master/Slave/Slave 配置，它工作正常並且正在複製所有更改。
我現在已經建立了一個 PerconaDB (mysql+galera+XtraDB) 5.6.30 3 節點集群，它工作正常。
Percona 集群中的一個節點被配置為第一個集群的 Replication Slave。這樣做是為了為遷移目的提供臨時同步；最終，Master/Slave 集群將被移除，我們將只使用 Percona 集群。
如果我使用 mysql 客戶端，並在 Master 上進行更改（添加表、添加記錄、更新記錄），那麼這會復製到所有客戶端以及 Percona 集群中的所有節點。到目前為止，一切都很好。
但是，如果我使用某個 Web 應用程序進行更改，那麼這些更改只會復製到主節點和原始從節點，而不會復製到任何 Percona 節點。
我已經驗證，如果我使用 mysql 手動進行更新，它們會正確複製；但是，如果通過 Web 應用程序完成，它們似乎會被 PerconaDB 從節點過濾掉。請注意，我對應用程序使用的確切 SQL 沒有任何可見性，並且無法停止數據庫以啟用查詢日誌記錄。
使用
SHOW SLAVE STATUS並且SHOW MASTER STATUS我可以看到當進行更改時，主伺服器和從伺服器上的日誌位置都在增加。當執行相同更新的“手動”SQL 命令似乎正確複製時，誰能告訴我為什麼 Percona 從執行緒會忽略來自 webapp 的更新？這是版本不兼容，是否有任何臨時解決方法？
主配置（部分）
[mysqld] binlog-format = mixed binlog-ignore-db = mysql binlog-ignore-db = information_schema expire_logs_days = 10 log-bin = /var/lib/mysql/mysql-bin server-id = 1 skip-external-locking sync_binlog = 1從站配置（部分）
[mysqld] server-id = 1000 log-slave-updates = 1 relay-log = /var/lib/mysql/mysql-relay-bin.log log_bin = /var/lib/mysql/mysql-bin.log slave-skip-error = 1062,1050 replicate-ignore-db = mysql replicate-ignore-db = information_schema replicate-ignore-db = performance_schema大師狀態：
File: mysql-bin.000027 Position: 1563 Binlog_Do_DB: Binlog_Ignore_DB: mysql,information_schema奴隸狀態：
Slave_IO_State: Waiting for master to send event Master_Host: x.x.x.x Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000027 Read_Master_Log_Pos: 1563 Relay_Log_File: mysql-relay-bin.000012 Relay_Log_Pos: 269 Relay_Master_Log_File: mysql-bin.000027 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: mysql,information_schema,performance_schema Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 1563 Relay_Log_Space: 442 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_UUID: Master_Info_File: /var/lib/mysql/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0從端出現的警告：
2016-09-07 20:16:26 21354 [Warning] Slave I/O: Notifying master by SET @master_binlog_checksum= @@global.binlog_checksum failed with error: Unknown system variable 'binlog_checksum', Error_code: 1193 2016-09-07 20:16:26 21354 [Warning] Slave I/O: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.1.73-log), even though it is on the slave (version: 5.6.30-76.3-56-log), Error_code: 1193
找到了答案。在過去的某個時候，有人重新配置了 5.1 集群，使節點 2 成為主節點，節點 1 成為從節點。這意味著我實際上是從從屬伺服器複製到 Galera 集群，並且應用程序正在寫入節點 2。
這應該仍然有效；但是舊的主節點（節點 1）沒有
log-slave-updates設置，因此通過（主節點）節點 2 進入的應用程序的更新不會復製到 Galera 集群。我更改為從節點 2（真正的主節點）複製，一切都按預期工作。
因此，總而言之，這是一個第 8 層問題（IE，使用者錯誤），是由從沒有設置 log-slave-updates 的從屬複製引起的。