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

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

排查方法：

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

解決方法：

給無(wú)主鍵表增加主鍵，給缺少二級(jí)索引的表增加索引。

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

解決方法：

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

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

排查方法：

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

解決方法：

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

只讀實(shí)例、DRS災(zāi)備實(shí)例的規(guī)格小于主實(shí)例時(shí)，一旦主實(shí)例寫(xiě)負(fù)載升高到一定程度，只讀實(shí)例或DRS災(zāi)備實(shí)例會(huì)因?yàn)樽陨碣Y源不足，無(wú)法及時(shí)回放Binlog，導(dǎo)致復(fù)制延遲增加。

解決方法：

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