RDS for MySQL的Binlog采用row格式，對每一行的數(shù)據(jù)更新，都會形成row格式Binlog event記錄。例如：一個update語句更新100行數(shù)據(jù)，那么row格式的Binlog中會形成100行update記錄，備機(jī)或只讀回放時會執(zhí)行100次單行update。

只讀節(jié)點和備機(jī)在回放主庫的Binlog event時，會根據(jù)表的主鍵或者二級索引來檢索需要更改的行。如果對應(yīng)表未創(chuàng)建主鍵，則會產(chǎn)生大量的全表掃描，從而降低了Binlog日志的應(yīng)用速度，產(chǎn)生復(fù)制延遲。

排查方法：

通過show create table xxx，分析執(zhí)行慢的update和delete語句對應(yīng)的表，分析是否有主鍵。

解決方法：

給無主鍵表增加主鍵，給缺少二級索引的表增加索引。

DDL操作往往執(zhí)行時間很長，尤其是表數(shù)據(jù)量很大時。通常情況下，只讀節(jié)點或備機(jī)回放一個DDL操作的時間和主庫花費的時間基本一致。因此，當(dāng)主機(jī)執(zhí)行了大表的DDL操作后，備機(jī)和只讀節(jié)點在回放該DDL期間，復(fù)制時間必然是一致增大的。

解決方法：

該場景為正?，F(xiàn)象，等DDL執(zhí)行完成后，主備復(fù)制延遲才能恢復(fù)。建議在業(yè)務(wù)低峰期執(zhí)行DDL操作。

只讀實例上往往有業(yè)務(wù)流量，如果存在只讀長事務(wù)正在執(zhí)行，會阻塞主實例同步過來的相應(yīng)表的DDL操作，卡在了表MDL鎖獲取，進(jìn)而阻塞所有同表的后續(xù)Binlog回放，導(dǎo)致復(fù)制延遲越來越大。

排查方法：

1. 登錄只讀節(jié)點，使用如下命令，觀察是否有長時間執(zhí)行的事務(wù)。
2. select t.*,to_seconds(now())-to_seconds(t.trx_started) idle_time from INFORMATION_SCHEMA.INNODB_TRX t \G;
3. 查看只讀節(jié)點的MDL鎖視圖，觀察是否有MDL鎖沖突。
4. select * from information_schema.metadata_lock_info;
5. 根據(jù)MDL鎖視圖中的線程ID，找到阻塞的session。更多信息，請參見MDL鎖視圖。

解決方法：

kill只讀節(jié)點上阻塞DDL操作的長事務(wù)，或者在業(yè)務(wù)側(cè)提交該長事務(wù)。

只讀實例、DRS災(zāi)備實例的規(guī)格小于主實例時，一旦主實例寫負(fù)載升高到一定程度，只讀實例或DRS災(zāi)備實例會因為自身資源不足，無法及時回放Binlog，導(dǎo)致復(fù)制延遲增加。

解決方法：

只讀實例或DRS災(zāi)備實例擴(kuò)大規(guī)格，與主實例規(guī)格匹配。