并發(fā)復(fù)制parallel replication系列一

MySQL并發(fā)復(fù)制系列一：binlog組提并發(fā)復(fù)制（PMySQL并發(fā)復(fù)制系列一：binlog組提并發(fā)復(fù)制（ParallRn）系列一:BnayLogGroupMySQL MySQLBinarylogInnoDB儲(chǔ)引redoundosafecrashrecovery據(jù)庫，當(dāng)數(shù)crashrecoveryredoredologprepared但是cmmttransactionsundolog做rollback。然后客戶端連接時(shí)就能看到已MySQLBinarylog1二階段提交StorageEngine(InnoDBBinarylogMySQLcrashrecoveryprepare階段crash，數(shù)據(jù)recovery的時(shí)候該事Binarylog并且存儲(chǔ)引擎未提交，將該事務(wù)rollback。當(dāng)事務(wù)在Bnarygfsyc(crash未來得及,LyL中cmmit況下怎么保證存儲(chǔ)引擎和BinaryLog提交的順序一致？當(dāng)多個(gè)事務(wù)并發(fā)提交的情況，如BinaryLog和存圖2InnoDB存儲(chǔ)引圖2InnoDB存儲(chǔ)引擎提交的順序與MySQL上層如上圖：事務(wù)按照T1、T2、T3順序開始執(zhí)行，將二進(jìn)制日志（按T1、T2、T3順序）寫入日志文件commit將日志文件永久寫入磁盤，但是存儲(chǔ)引擎提交的順序T2統(tǒng)緩存，調(diào)用fsync()進(jìn)行一次T3、T1。T2、T3提交事務(wù)之后做On-linebackup程序新建一個(gè)slavereplication，那么SlavechangemastertoT33通過prepare_commit_mutex保證存儲(chǔ)引擎和二進(jìn)制日3通過prepare_commit_mutex保證存儲(chǔ)引擎和二進(jìn)制日志順序提交順序圖3可以看出在prepare_commit_mutex，只有當(dāng)上一個(gè)事務(wù)commit后釋放鎖，下一個(gè)事務(wù)才可以進(jìn)行sync_binlog參數(shù)來設(shè)置多少個(gè)binlog日志產(chǎn)生的時(shí)候調(diào)用一次fsync()把二進(jìn)制日志刷入磁盤來提高整體，二進(jìn)制日志groupcommitSyncstage、Commitstage存儲(chǔ)引擎（InnoDB)數(shù)據(jù)庫上層(Binary----Sync--------調(diào)存儲(chǔ)引擎（InnoDB）Commitleaderfollower，leaderleaderfollower，leaderfollower圖4:二進(jìn)制日志三階段提交過程Flushstagebinarylog么為了groupcommit中一組隊(duì)列的事務(wù)數(shù)量，MySQL用binlog_max_flush_queue_time來控制在FlushMySQL5.7Parallelreplication現(xiàn)主備多線程復(fù)制基于主BinaryLogGroupCommit,Binarybinlog_group_commit_sync_delay=N和binlog_group_comm