Вопрос не в том, как решить проблемы с репликацией, а в том, чтобы найти ошибки, вызванные медленной репликацией.Для повышения производительности мы не хотим, чтобы все запросы были синхронными, просто запросы, которые мы определяем как критическое чтение.
Иногда у нас возникают ошибки, связанные с синхронизацией в нашем кластере galera.Например, наше веб-приложение выполняет перенаправление после записи данных, но показывает устаревшее состояние на следующей странице.В среде разработки у нас нет этих проблем.При работе с некоторой нагрузкой на сервер другой узел иногда не синхронизируется, если мы читаем данные, записанные за несколько миллисекунд до этого.
Чтобы решить эту проблему, мы используем закрепление узла для критических чтений, чтобы читать с того же узла, что и записанораньше и мы экспериментируем с SET SESSION wsrep-sync-wait=6; для INSERT / UPDATES / DELETE, как описано здесь до избегаем уменьшения этого поведения (и теперь с битом "1", как rick-james упоминается).
Как проверить наличие ошибок, вызванных медленной репликацией?
Наша идея состоит в том, чтобы смоделировать очень медленную синхронизацию, чтобы протестировать наше приложение на наличие критическихчитать поведение.Есть ли какая-либо опция конфигурации, позволяющая кластеру galera работать как при большой нагрузке?Galera имеет встроенный контроль потока для замедления, но я не смог найти надежный способ заставить кластер управлять потоком.Решение не должно полагаться только на MySQL, также может быть полезен медленный виртуальный том в сочетании с чем-то вроде «innodb_flush_method».
(Обновлено, надеюсь, улучшить вопрос)