Медленные запросы на подчиненном устройстве MySQL

Предположим, что есть система, в которой есть главный сервер MySQL и подчиненный.

На главном сервере происходит много операций чтения/записи, и я решил выполнить тяжелый медленный запрос на ведомом.

Что может случиться? Может ли главный сервер немного замедлиться?


person XCore    schedule 20.03.2014    source источник
comment
Я не уверен, что вы можете настроить его по-другому, но на моей работе мастер ждет подтверждения подчиненного, поэтому ответ будет «да», это повлияет на мастера.   -  person Olvathar    schedule 20.03.2014
comment
Итак, например, предположим, что ведомое устройство в какой-то момент выйдет из строя, что сделает Мастер?   -  person XCore    schedule 20.03.2014
comment
Несколько недель назад у нас произошел сбой на подчиненном сервере, в результате чего оставшийся запрос на вставку в таблицу MyISAM был остановлен, что заблокировало любую другую петицию, и все рухнуло. Извините, я не администратор базы данных, и я просто сообщаю, что сказал наш администратор: D   -  person Olvathar    schedule 20.03.2014
comment
@Olvathar, лол, могу поспорить, у тебя были замечательные моменты в офисе ;)   -  person XCore    schedule 20.03.2014
comment
Просто чтобы прояснить, вы спрашиваете о репликации и какой версии сервера MySQL?   -  person Marcus Adams    schedule 20.03.2014
comment
@MarcusAdams, ммм, о главном\ведомом, я говорю о репликации. Но на самом деле я говорю о чем-то вроде этого: у нас есть главная БД, которая имеет высокую скорость чтения\записи. Тогда есть подчиненный, который служит репликой. Тем не менее, я пытаюсь выполнить ммм, давайте назовем это анализом данных. Я не хочу блокировать основную базу данных, поэтому я планировал использовать подчиненную. Но я не уверен, что это может принести какую-то пользу.   -  person XCore    schedule 20.03.2014


Ответы (1)


Использование реплицированного подчиненного сервера для запросов только для чтения для таких вещей, как создание отчетов, является обычной практикой.

Репликация на мастере читает из файла журнала и не затрагивает фактические таблицы базы данных. Репликация на главной стороне не выполняет никаких запросов, поэтому реальной нагрузки на базу данных нет.

Репликация имеет собственный поток на главном сервере, и пока он заблокирован, он не должен останавливать нормальную работу базы данных.

Репликация MySQL способна полностью восстановиться после сбоя и автоматически продолжится с того места, где она остановилась.

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

Это означает, что если вы запускаете запрос, который просто полностью тормозит подчиненный сервер, вы можете увидеть задержку до 10 секунд на главной стороне, но после этого ничего не должно влиять. Вы можете настроить время ожидания.

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

person Marcus Adams    schedule 20.03.2014