slave_preserve_commit_order - xiaoboluo768/qianjinliangfang GitHub Wiki

• 用于控制从库并行复制时，重放binlog是否完全按照主库的提交顺序进行提交。
  • 对于多线程从库，启用此变量可确保事务在从库上以与从库的中继日志中显示的相同的顺序进行应用。此变量对于不启用多线程的从库没有影响。
  • 该参数为布尔型，全局变量，动态变量。5.7.5版本引入。默认值为0，有效值为0和1
    • 在使用并行复制的从库中，当从库启用slave_preserve_commit_order（为1时）之后，并行应用的事务将完全按照主库的binlog中记录的顺序进行提交，同一个group commit中的事务并行应用时，如果在这个顺序之后的事务先提交，则在commit这个动作时需要等到在这个顺序前面的事务提交之后才能提交。当线程等待其他worker线程提交其事务时，其状态显示为“Waiting for preceding transaction to commit”。 （在MySQL 5.7.8之前，这被显示为“Waiting for its turn to commi”），在多线程从库上启用此模式可以确保主备数据的一致性。这使得它非常适合用于复制读横向扩展（可以使用从库克隆一份数据来搭建新的从库，以达到扩展从库读性能的目的）
    • 在使用并行复制的从库中，如果未启用slave_preserve_commit_order（为0时），则从从库的中继日志执行的事务顺序有可能出现间隙(当启用此选项时，就不会出现间隙)，Exec_master_log_pos可能位于已执行的位置之后（可能整个group commit的binlog position需要等到对应的事务group执行完才能提交，在整个事务group执行过程中，有一部分事务已经提交了，但是binlog还没有提交，那么可能在从库crash之后，binlog pos位置和事务的位置对不上，binlog pos中记录的事务位置在存储引擎中的事务位置之前（更早的位置，也就是说丢失了最后一个group commit中已提交事务的binlog pos））
  • 虽然可以动态修改该变量，但是必须先停止所有复制线程（如果使用多个复制通道（多源复制），那么需要停止所有复制通道）。当该变量设置为1时，必须在从库上启用--log-bin和--log-slave-updates。另外--slave-parallel-type必须设置为LOGICAL_CLOCK。

---

上一篇：slave_rows_search_algorithms | 下一篇：log_bin_trust_function_creators