Репликация mySQL имеет непосредственную согласованность данных?

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

Тем не менее, я смущен тем, почему реляционная база данных претендует на сильную согласованность данных. Думаю, я должен использовать транзакции, и это даст мне сильную последовательность. Хорошо ли тогда писать приложения, предполагая, что репликация mySQL может отставать?

Ответ 1

Согласованность в том смысле, в каком она используется в ACID, означает, что все ограничения выполняются до и после любого изменения. Когда система уверяет, что вы не можете прочитать данные, которые являются непоследовательными, они, например, говорят, что вы никогда не будете читать данные, когда дочерняя строка ссылается на несуществующую родительскую строку или где была применена половина транзакции, кроме другая половина еще не была применена (в примере из учебника списывается один банковский счет, но еще не зачислен на банковский счет получателя).

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

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

Таким образом, вы можете временно прочитать старые данные в системе репликации, которая отстает, но вы не будете читать противоречивые данные.

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

Вы правы в том, что вам, возможно, нужно быть осторожным при чтении из реплик, если ваше приложение требует абсолютно текущих данных. Каждое приложение имеет различный допуск для задержки репликации, и фактически в пределах одного приложения разные запросы имеют различный допуск для задержки. Я сделал презентацию об этом: http://www.slideshare.net/billkarwin/read-write-split