innodb_flush_log_at_trx_commit和sync_binlog有什么区别？

Question

我正在阅读影响InnoDB持久性的内容，并找到2配置字段。我有以下问题：

1. 2配置字段之间的区别是什么？我的第一个猜测是innodb_flush_log_at_trx_commit会影响InnoDB重做日志，而sync_binlog会影响MySQL标准的二进制日志。对吗？
2. 我的第二个问题是，是否将日志记录过程分为三个阶段:写到缓冲区、写到os缓存、刷新到磁盘。那么第二次复制是在哪个阶段发生的呢?关于
3. 关于sync_binlog，我有另外一个问题。如果sync_binlog设置为0，则按照innodb的说法，刷新不是在提交，而是委托给OS。是否在提交之前对binlog进行了同步，以便复制看到未提交的数据？

Answer 1

将innodb_flush_method添加到列表中。

innodb_flush_log_at_trx_commit应该是1表示安全性(在崩溃时不会丢失任何数据)或2表示速度。(我认为0是出于历史原因而没有优势的。)

sync_binlog避免奴隶试图读取主的二进制日志的结尾(在崩溃后)。由于数据已经发送给奴隶，这不是一个“数据丢失”问题，而是一个恼人的错误，很容易通过手工纠正(将其移动到下一个二进制日志)。

我认为这是复制步骤的顺序。注意:在事务的情况下，直到COMMIT才会发生任何事情。(另见“binlog_cache_size”)

• 将数据发送到从站，并在sync_binlog打开时将副本刷新到二进制日志(否则，让它最终被刷新)。(我不知道首先发生了什么，甚至不知道它们是否由单独的线程完成。)从服务器上的I/O线程将数据复制到它的“中继log".
• Eventually (通常是马上)，执行线程执行query.
• (Multi-source复制和并行执行对从服务器添加进一步的complications.)
• Semi-sync介入somewhere.
• Galera --参见"gcache"，等等。

什么叫“二次复制”。

您的第3项可能指的是一种模糊的情况，在这种情况下，某些东西可能会从裂缝中掉下来，因为涉及太多的硬件部件。

如果您想要可靠性，请参阅Galera群集和/或InnoDB群集。这超出了简单的主从复制，即使是半同步。