Я настроил два сервера 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 для предотвращения / уменьшения задержки?
Я столкнулся именно с этой проблемой с настройкой master -> many slave. Это было даже хуже, чем ваша ситуация, потому что считывание было гарантировано от ведомого, а не с вероятностью 50/50.
Каждый раз, когда пользователь писал в базу данных (например, сообщение на форуме или нажимал кнопку «Нравится»), он получал HTTP-перенаправление на страницу, должен показать их сообщение, но это никогда сделал. Время приема-передачи перенаправления и последующего запроса было короче, чем задержка репликации.
Наблюдая за отставанием SHOW SLAVE STATUS показал, что это почти всегда меньше секунды. Однако время от времени он все же становился выше. Поскольку репликационный SQL является однопоточным, 10-секундный медленный запрос вызовет 10-секундную задержку в вашей репликации.
Решением для нас стало изменение всех наших «только что отправленных» страниц так, чтобы они всегда считывались с ведущего устройства, а не с ведомого. В вашем случае будет сложно убедиться, что каждый веб-сервер знает, в какую базу данных только что написал предыдущий запрос.
Лучшим решением может быть вставка недавно записанных данных в экземпляр memcached. Даже если у ваших данных memcached есть время истечения 10 секунд, этого должно быть достаточно, чтобы покрыть задержку репликации.
Это зависит от производительности ваших серверов, которая связана с тем, сколько запросов должен обработать каждый сервер, насколько велики ваши таблицы и так далее. Использование такого решения репликации должно быть синхронным, что определенно вызовет некоторую задержку во время транзакций. Это просто потому, что каждую транзакцию нельзя считать совершенной полностью, если это не сделано на обоих узлах.
Я думаю безопаснее вариант - сбалансировать запросы на основе исходного IP-адреса клиента (если это поддерживается / возможно). В этом случае все запросы, поступающие от одного и того же клиента, будут перенаправлены на один и тот же сервер БД.
Задержка зависит в первую очередь от:
Раньше вычислить отставание невозможно. Я могу предложить провести несколько интенсивных (для вас) тестов с параллельными операциями записи и чтения.