В чем разница между innodb_flush_log_at_trx_commit и sync_binlog? - PullRequest
Новая
       14

В чем разница между innodb_flush_log_at_trx_commit и sync_binlog?

0 голосов
/ 09 марта 2020

Я читаю, что влияет на долговечность InnoDB, и нахожу 2 поля конфигурации. У меня есть следующие вопросы:

  1. В чем разница между двумя полями конфигурации? Мое первое предположение заключается в том, что innodb_flush_log_at_trx_commit влияет на журнал повторного выполнения InnoDB, а sync_binlog влияет на стандартный MySQL binlog. Я прав?
  2. Мой второй вопрос: если процесс регистрации делится на 3 фазы: запись в буфер, запись в кэш os, flu sh на диск. Тогда на каком этапе происходит вторичная репликация?
  3. о sync_binlog, у меня есть еще один вопрос. Если sync_binlog установлен в 0, в соответствии с innodb do c, flu sh не находится в коммитах, а делегирован ОС. Может ли быть так, что binlog синхронизируется перед фиксацией, чтобы репликация увидела данные не зафиксированными?

1 Ответ

1 голос
/ 24 марта 2020

Добавьте innodb_flush_method в список.

innodb_flush_log_at_trx_commit должно быть 1 для безопасности (не потеряет любые данные в крейте sh) или 2 для скорости. (0, я думаю, существует по историческим причинам c и не имеет никакого преимущества.)

sync_binlog избегает, чтобы Раб пытался прочесть конец бинарника Мастера (после крэя sh). ). Поскольку данные уже были отправлены на ведомые устройства, это не проблема «потери данных», а досадная ошибка, которую легко исправить вручную (переместите ее в следующий журнал).

Я думаю, что это порядок шагов репликации. Примечание. В случае транзакции ничего не происходит до COMMIT. (См. Также «binlog_cache_size».)

  • Отправьте данные на ведомые устройства и flu sh скопируйте в binlog, если включен sync_binlog (иначе пусть он в конечном итоге будет сброшен). (Я не знаю, что произойдет первым, и даже не будут ли они выполнены отдельными потоками.)
  • Поток ввода-вывода на подчиненном устройстве копирует данные в свой «релейный журнал».
  • В конце концов (обычно сразу) поток выполнения выполняет запрос.
  • (репликация с несколькими источниками и параллельное выполнение на подчиненном устройстве усложняют работу.)
  • Semi-syn c получает где-то участвует.
  • Galera - см. "gcache", et c.

Что вы подразумеваете под "вторичной репликацией".

Ваш предмет 3 возможно, имеется в виду неясный случай, когда что-то может упасть сквозь трещины, потому что задействовано слишком много оборудования.

Если вам нужна надежность, см. Galera Cluster и / или InnoDB Cluster. Это выходит за рамки того, что доступно с простой репликацией Master-Slave, даже с полусинхронным c.

...