MySQL Master-Master Lag репликации
Я настроил два сервера MySQL (MySQL-1, MySQL-2) в master-master репликация в том же центре данных с использованием локального внутреннего соединения со следующими параметрами:
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Мы используем балансировщик нагрузки, чтобы округлять запросы MySQL назад и вперед одинаково между двумя серверами MySQL. Это прекрасно работает, но меня беспокоит задержка репликации. Например, если пользователь A вставляет строку в MySQL-1, а затем пользователь A выбирает из MySQL-2, данные, возможно, не были успешно реплицированы.
В основном, мой вопрос: сколько следует ожидать задержки (миллисекунды, секунды)? Есть ли у них больше вариантов MySQL для предотвращения / уменьшения лагов?
3 ответа
Это зависит от производительности ваших серверов, которая зависит от того, сколько запросов должен обработать каждый сервер, насколько велики ваши таблицы и так далее. Использование такого решения для репликации должно быть синхронным, что определенно приведет к некоторой задержке во время транзакций. Это просто потому, что каждая транзакция не должна считаться принятой полностью, если это не сделано на обоих узлах.
Я думаю, что более безопасным вариантом является балансировка запросов на основе исходного IP-адреса клиента (если это поддерживается / возможно). В этом случае все запросы, поступающие от одного и того же клиента, будут перенаправлены на один и тот же сервер БД.
Я столкнулся именно с этой проблемой с мастером -> многими ведомыми настройками. Это было даже хуже, чем в вашей ситуации, потому что показания были гарантированно получены от раба, а не с вероятностью 50/50.
Каждый раз, когда пользователь пишет в базу данных (например, на форуме или нажимает кнопку "Мне нравится"), он получает HTTP-перенаправление на страницу, на которой должно отображаться его сообщение, но этого не происходит. Время кругового обхода перенаправления и последующего запроса было меньше, чем задержка репликации.
Наблюдая за отставанием с SHOW SLAVE STATUS показал, что это было почти всегда меньше секунды. Однако иногда оно становилось выше, чем это. Поскольку репликационный SQL является однопоточным, 10-секундный медленный запрос вызовет 10-секундную задержку в вашей репликации.
Решение для нас закончилось тем, что мы изменили все наши "только что опубликованные" страницы, чтобы они всегда читались с мастера, а не с раба. В вашем случае, удостовериться, что каждый веб-сервер знает, в какую базу данных только что записан предыдущий запрос, будет сложно.
Лучшим решением может быть добавление недавно записанных данных в экземпляр memcached. Даже если ваши кэшированные данные имеют срок действия 10 секунд, этого должно быть достаточно для покрытия задержки репликации.
Лаг зависит в основном от:
- количество операций записи (вставки и обновления)
- аппаратное обеспечение (скорость диска и процессор)
- загрузка сервера (выбрать)
Невозможно рассчитать отставание раньше. Я могу предложить сделать несколько интенсивных (для вас) тестов с операциями одновременного чтения и записи.