почему первичный отбор innodb не учитывает "соответствие" со старым первичным

Question

Когда я читаю репликацию данных с первичного сервера на вторичные серверы InnoDB. Меня удивляет, что репликация асин c или, по крайней мере, полуасин c. Поэтому у меня возникает следующий вопрос, что в случае асинхронной репликации c основной сервер может go отключиться, так как некоторые его вторичные узлы не получают информацию о репликации. И последующий выбор следующего первичного не учитывает, какой вторичный является ближайшим к старому первичному, и, таким образом, может быть выбран один узел без некоторой последней асинхронной репликации c. Таким образом, можем ли мы сделать вывод, что первичный-вторичный кластер не согласован?

Answer 1

Этот вопрос почти совпадает со старым, на который я ответил: Имеет ли репликация mySQL немедленную согласованность данных?

Вы правы в том, что существует риск потери данных в асинхронном наборе реплик. Если основной объект потерян, возможно, его реплики не применили последние изменения. Даже в том, что MySQL называет "полусинхронным", реплика может получать журналы всех событий, но еще не применять их.

В сценарии отработки отказа наиболее безопасно, если реплика остается доступной только для чтения и не позволяет клиентам записывать себя до тех пор, пока она полностью не «догонит», применив все ожидающие журналы.

Вы должны разрабатывать приложения так, чтобы они терпели задержки, когда это происходит.

Мы бы хотели, чтобы все было полностью согласованным и доступным без задержек, но единственный возможный способ - это если каждая транзакция, зафиксированная на первичном сервере, должна ждать, пока те же изменения будут применены к реплике.

В большинстве компаний это не компромисс, который они готовы принять. Они предпочли бы, чтобы транзакции выполнялись на первичном сервере как можно быстрее при нормальных условиях, и принимали бы небольшой риск потери данных при переключении.