MySQL / MariaDB предпочитает чтение с ведомого устройства с максимальной степенью устаревания

Я использую Mysql / MariaDB с механизмом хранения Innodb версии 10.x.

Я хочу настроить кластер с конфигурацией главный-подчиненный. Есть возможность читать данные с ведомого устройства с помощью --innodb-read-only или --read-only.

Однако в дополнение к вышесказанному клиенту необходимо считывать данные с ведомого устройства тогда и только тогда, когда максимальная задержка ведомого устройства составляет менее x секунд.

Подчиненные устройства могут отставать от основного из-за перегрузки сети, низкой пропускной способности диска, длительных операций и т. Д. Предпочтение чтения с опцией максимально допустимой устаревания должно позволять приложению указывать максимальную задержку репликации или «устаревание» для операций чтения с ведомых устройств. Когда предполагаемая степень устаревания вторичного сервера превышает его, клиент прекращает использовать его для операций чтения с ведомых устройств и начинает чтение с ведущего устройства.

Я хотел бы знать, есть ли опция в MySql / InnoDB?


mysql mariadb innodb database-replication eventual-consistency
person Lokendra Chauhan    schedule 06.07.2018    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Нет автоматической опции для переключения запроса на мастер. Это обрабатывается логикой приложения.

Вы можете запустить запрос SHOW SLAVE STATUS, и одно из возвращаемых полей будет Seconds_Behind_Master. Вам придется написать код приложения, чтобы проверить это, и если задержка превышает ваш порог, вместо этого запросите мастер.

Вы можете найти какой-нибудь прокси, который сделает эту логику за вас. См. https://mydbops.wordpress.com/2018/02/19/proxysql-series-mysql-replication-read-write-split-up/

Не всегда лучший вариант рассматривать реплику с задержкой в ​​X секунд как непригодную для использования. С некоторыми запросами все в порядке, независимо от задержки. Несколько лет назад я написал об этом презентацию, и она включает несколько примеров запросов. Разделение чтения / записи с MySQL и PHP (веб-семинар Percona, 2013 г.)

person Bill Karwin    schedule 06.07.2018
comment
Это именно то, что я искал. На самом деле мой кластер базы данных не должен быть строго согласованным и может допускать задержку в несколько минут. В любом случае я бы попробовал ProxySQL. Было бы здорово, если бы вы могли поделиться некоторой информацией о вариантах использования в реальном времени. Большое спасибо. - person Lokendra Chauhan; 06.07.2018
comment
Вы смотрели презентацию, на которую я ссылался? Это там. - person Bill Karwin; 06.07.2018
comment
Да, Билл. Также было замечено, что ProxySQL отказоустойчив или высокодоступен после выпуска v1.4.9. Это выглядит многообещающе ... Мне нужно настроить кластер БД в разных регионах и посмотреть, как я буду развертывать кластер ProxySQL вместе с этим. Так спросил о любой ссылке на это. Неважно. Спасибо. - person Lokendra Chauhan; 06.07.2018
comment
О, я думал, вы имели в виду варианты использования разделения чтения / записи в целом. Я не могу вам помочь с конкретным использованием ProxySQL, я сам не использовал его. - person Bill Karwin; 06.07.2018

arrow_upward
0
arrow_downward

  • Есть много продуктов Proxy, которые могут иметь такой код.
  • Если вы автоматически переключаетесь на Мастер, то он может быть перегружен, что приведет к более серьезной проблеме с системой.
  • Если вы попытаетесь переключиться на другого Slave, слишком легко попасть в нестабильную ситуацию.
  • У Galera есть способ справиться с «критическим чтением», если вы хотите перейти к настройке кластера вместо Master + Slaves.
  • Если часть проблемы заключается в расстоянии между ведущим и ведомым, и если вы переключитесь на ведущего, где находится клиент? Если он находится рядом с ведомым устройством, разве добавленное время для достижения ведущего не сведет на нет некоторые преимущества?
  • Избегайте длительных запросов, улучшите Slave, чтобы избежать медленных дисков, ускорить запросы, которые часто попадают на диск, изучите возможности улучшения сети.

Таким образом, мне не нравится идея попытки переместить запрос к Мастеру; Я буду работать над решением основной проблемы.

person Rick James    schedule 07.07.2018

arrow_upward
0
arrow_downward

MariaDB MaxScale имеет несколько способов борьбы с задержкой репликации.

Самый простой способ - ограничить максимально допустимую задержку репликации с помощью max_slave_replication_lag < / a> параметр. Это работает точно так, как вы описали: если ведомое устройство находится слишком на много секунд позади ведущего, используются другие ведомые устройства и, в крайнем случае, ведущее устройство. Это наиболее распространенный метод борьбы с задержкой репликации в MaxScale.

Другой вариант - использовать функцию causal_reads, которая использует MASTER_GTID_WAIT и другие функции, имеющиеся в MariaDB 10.2 и более новых версиях. Это обеспечивает согласованность чтения без дополнительной нагрузки на мастер. Это происходит за счет задержки: если сервер отстает на несколько секунд, чтение может занять больше времени. Эта опция используется, когда согласованность данных критична, но задержка запроса не так важна.

Третий вариант - использовать CCRFilter для принудительного чтения мастеру после того, как произошла запись. Это более простой подход по сравнению с causal_reads, но он обеспечивает согласованность данных за счет увеличения нагрузки на ведущее устройство.

person markusjm    schedule 13.12.2019