Дублирующий MySQL

[kozak]

Насколько я понял, DELAY_KEY_WRITE вообще не имеет никакого отношения к репликации?
Параметр работает локально.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Gamerman]

В мануале все есть.

В: Как прокручивать журналы репликации?

О: В версии 3.23.28 нужно использовать команду PURGE MASTER LOGS TO после определения тех журналов, которые должны быть удалены, и выборочно сделать резервные копии этих журналов. В более ранних версиях этот процесс намного более трудоемкий, и не может быть безопасно выполнен без остановки всех подчиненных серверов, если планируется повторное использование имен журналов. Нужно будет остановить потоки подчиненного сервера, отредактировать индексный файл двоичного журнала, удалить все старые журналы, перезапустить головной сервер, запустить потоки подчиненного сервера и затем удалить файлы старых журналов.

В: Как сделать апгрейд сервера во время репликации?

О: Если модернизируемая версия ниже 3.23.26, нужно лишь блокировать таблицы головного сервера, позволить подчиненному серверу подогнать обновления, затем выполнить команду FLUSH MASTER на головном сервере и команду FLUSH SLAVE на подчиненном сервере, чтобы очистить журналы, затем перезапустить новые версии на головном и подчиненном серверах. Обратите внимание: подчиненный сервер может останавливаться на некоторое время - пока головной сервер записывает в журнал все обновления, подчиненный сервер будет способен подогнать обновления как только сможет начать работу и подсоединиться к головному серверу.

В версиях выше 3.23.26 осуществляется блокировка протокола репликации для обновлений. Таким образом можно делать апгрейд до более свежей версии 3.23 головного и подчиненного серверов динамически. Помимо этого, на головном и подчиненном серверах могут быть запущены различающиеся версии MySQL, если обе версии выше 3.23.26.

Q: Какие проблемы могут возникать при установке двухсторонней репликации?

A: В настоящее время для репликаций MySQL не поддерживается никакого протокола блокировки между головным и подчиненным сервером, который обеспечивал бы неделимость распределенных (междусерверных) обновлений. Другими словами, клиент A может делать обновления на головном сервере 1, и в это же время, перед тем, как эти обновления скопируются на головной сервер 2, клиент B может делать обновления на головном сервере 2, из-за которых обновления клиента A будут выполняться не так, как на головном сервере 1 компании. Таким образом, когда обновления, сделанные клиентом A, будут перенесены на головной сервер 2, таблицы, полученные в результате, будут отличаться от таблиц на головном сервере 1. В этом случае таблицы на двух серверах будут разными, даже если обновления, произошедшие на головном сервере 2, также будут скопированы на головной сервер 1. Отсюда следует, что не стоит соединять в цепочку два сервера двусторонней репликационной связью, если вы не уверены, что обновления будут безопасно выполняться в любом порядке, или если вы не обрабатываете каким-либо образом такие неупорядоченные обновления где-либо в клиентском коде.

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

Q: Как использовать репликацию для повышения производительности системы?

A: Установите один сервер как головной и направляйте все записи к нему, а также сконфигурируйте такое количество подчиненных серверов, на какое у вас хватит средств и дискового пространства, и распределите чтение между головным сервером и подчиненными серверами. Можно также запустить подчиненные серверы с опциями --skip-bdb, --low-priority-updates и --delay-key-write=ALL, чтобы получить увеличение скорости на подчиненном сервере. В данном случае подчиненный сервер для повышения скорости будет использовать нетранзакционные таблицы MyISAM вместо таблиц BDB.

Q: Что нужно сделать, чтобы подготовить свой клиентский код для использования репликации, повышающей производительность?

A: Если та часть вашего кода, которая отвечает за доступ к базе данных, является достаточно абстрактной и модульной, преобразование ее для работы с установленной репликацией произойдет очень гладко и просто - для этого нужно лишь изменить реализацию доступа для чтения к базе данных от некоторого подчиненного сервера или головного сервера так, чтобы запись всегда производилась на головной сервер. Если же ваш код не имеет такого уровня абстракции, то установка системы репликации окажется для вас хорошей и мотивированной возможностью почистить свой код. Начните с создания библиотеки или оболочки со следующими функциями:

* Safe_writer_connect()
* Safe_reader_connect()
* Safe_reader_query()
* Safe_writer_query()

Префикс safe_ означает, что функция будет нести ответственность за обработку всех возникающих ошибок.

После этого нужно преобразовать клиентский код так, чтобы он использовал библиотеку оболочки. Вначале все это покажется лишней головной болью, но в конечном счете ваши усилия окупятся. Все приложения, построенные в соответствии с приведенной выше схемой, смогут "приобщиться" к преимуществам решения один головной/много подчиненных. Код будет гораздо легче поддерживать, а добавление опций поиска неисправностей станет тривиальным. К примеру, если вам захочется узнать, какой запрос среди многих тысяч возвращает ошибку или реализовать регистрацию продолжительности выполнения каждого запроса, то понадобится изменить всего пару функций. Если у вас уже написано много кода, то для автоматизации задачи его преобразования можно использовать написанную Монти утилиту replace, которая имеется в стандартном дистрибутиве MySQL, или написать собственный сценарий на Perl. Остается надеяться, что ваш код удовлетворяет некоторой распознаваемой схеме. В противном случае будет лучше переписать его каким-либо образом, или, по крайней мере, вручную подогнать его под схему.

[kozak]

mysql.ru

Установка в 1 задерживает операции обновления таблицы ключей, пока не закроется указанная таблица (MyISAM).