надійність реплікації
Для забезпечення максимальної надійності реплікації рекомендується встановити параметри MySQL наступним чином:
innodb_flush_log_at_trx_commit = 1
Примітка: Установка саме таких параметрів може привести до загального зниження продуктивності системи.
Для підвищення продуктивності можна використовувати такі параметри (може призвести до втрати даних декількох транзакцій в момент аварії на базі даних):
динамічний hostname
relay - log. relay - log - index.
привілеї
Для роботи реплікації облікові записи основного і резервних master / slave-серверів повинні мати, крім стандартних, також привілеї:
тимчасові зони
Якщо сервера СУБД кластера розташовані в різних дата-центрах, необхідно налаштувати на них єдину тимчасову зону.
адміністрування реплікації
Реплікація після настройки працює надійно і вимагає мінімального адміністрування. Проте, рекомендується періодично перевіряти її стан утилітами моніторингу операційної системи (nagios, zabbix, monit, linux-ha).
У малоймовірному випадку виникнення помилки на slave-сервері рекомендується його переініціалізіровать - заново залити на нього дані з основного сервера. Для цього потрібно його Припинити використовувати. а потім Почати використовувати в розділі Реплікація (Установки> Веб-кластер> Реплікація).
Можна вільно зупиняти slave-сервера, в т.ч. для здійснення логічного та цілісного бінарного резервного копіювання засобами MySQL і операційної системи. При цьому не припиняє будь-яке основного сервера СУБД.
Перемикання slave-> master в разі відмови master
У разі відмови основного (master) сервера СУБД, необхідно вручну або автоматично скриптом переключити кластер на інший master-сервер СУБД. Для цього зазвичай slave-сервер, який зберігає останні реплікованих дані, переводять в режим основного.
Загальна схема цієї процедури така:
- Закриваємо доступ клієнтів до веб-додатку Якщо використовується дворівнева конфігурація (фронтенд nginx - бекенда apache і т.п.), рекомендується на фронтендів відключити доступ до бекенда (веб-додатку) і віддавати при зверненні клієнтів до кластеру інформаційну сторінку про регламентні роботи.
- Зупиняємо на всіх slave-серверах потік отримання оновлень бінарного логу з основного (master) сервера: