Скорость репликации MySQL

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

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

2) Я внешний пользователь, я не знаю, что произошла команда CUD, и мне вообще все равно, поэтому возвращение устаревших данных приемлемо (в 99% реализаций, иначе вы, вероятно, не использовали бы PHP * ).

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

• Если вам нужны мгновенные обновления, вы можете попробовать записать в слой кеша, который опрашивается вместе с (потенциально ненадежными) данными БД. Что-то вроде memcached было бы первым кандидатом.

Это зависит от того, насколько быстро ваш ВЕДОМЫЙ сервер реплицирует данные с вашего ГЛАВНОГО сервера.

Если он напрямую связан с командами INSERT, UPDATE и DELETE, то есть когда вы что-то вставляете, вы фактически вставляете это в оба, скорее всего, он будет доступен в любом из них.

Если ВЕДОМЫЙ сервер реплицирует MASTER с помощью задачи, которая запускается так часто, чтобы получить данные от MASTER, что было бы дешевле, чем выполнение 2 запросов для каждого 1 запроса, это будет означать, что данные недоступны до тех пор, пока задача не будет выполнена. побежал.