файли реплікації
Тепер розглянемо деякі файли, які беруть участь в процесі реплікації. Про довічним журналі і журналі ретрансляції ви вже знаєте, але є й інші файлові об'єкти. Конкретне місце їх зберігання залежить в основному від конфігураційних параметрів MySQL. У різних версіях СУБД умовчання різні. Найчастіше їх можна знайти в каталозі даних або в каталозі, де знаходиться pid-файл сервера (в UNIX-системах це зазвичай каталог / var / run / mysqld /). Перерахуємо їх.
Якщо запис в двійковий журнал включена, то сервер створює файл з таким же ім'ям, як у довічних журналів, але з розширенням
index. У ньому реєструються всі файли довічних журналів, наявні на диску. Це не індекс в тому сенсі, в якому ми говоримо про індекси за таблицями; він просто складається з текстових рядків, в кожній з яких зазначене ім'я одного файлу довічного журналу. Ймовірно, у вас виникла думка, що цей файл зайвий і може бути видалений (в кінці кінців, MySQL може просто знайти всі файли на диску). Не робіть цього! MySQL ігнорує виконавчі журнали, які не вказані в індексному файлі.
Цей файл грає ту ж роль для журналів ретрансляції, що розглянутий вище файл для довічних журналів.
У цьому файлі зберігається інформація, необхідна підлеглому сервера для з'єднання з головним. Формат текстовий (по одному значенню в рядку) і змінюється в залежності від версії MySQL. Не знімайте його, інакше після перезапуску підлеглий сервер не буде знати, як підключитися до головного. Оскільки в цьому файлі може зберігатися пароль користувача у відкритому вигляді, буде розумно максимально обмежити права доступу до нього.
У цьому файлі на підпорядкованому сервері зберігаються ім'я його поточного довічного журналу і координати реплікації (тобто місце в довічним журналі головного сервера, до якого дійшов підлеглий). Не знімайте цей файл, інакше після перезапуску підлеглий сервер не буде знати, з якого місця продовжити реплікацію, і спробує відтворити вже виконані команди.
Сукупність цих файлів є досить прямолінійний спосіб зберегти стан реплікації і журналів. На жаль, запис в них проводиться не синхронно, тому якщо відбудеться збій харчування в момент, коли файли не обнулені на диск, то після перезапуску дані в них виявляться некоректними.
За замовчуванням ім'я довічного журналу утворюється з імені хоста, до якого додається цифровий суфікс, але краще задати базове ім'я явно в файлі my.cnf:
log_bir # Не робіть цього, якщо не хочете,
log_bin_index = mysql-bin.index relay_log = mysql-relay-bin
Взагалі-то index-файли за замовчуванням успадковують імена від відповідних файлів журналів, але не буде ніякої шкоди, якщо задати їх явно.
На index-файли впливає також параметр expire_logs_days, що визначає, скільки часу MySQL повинен зберігати вже закриті виконавчі журнали. Якщо у файлі mysql-bin.index згадуються файли, відсутні на диску, то автоматичне видалення працювати не буде; навіть команда PURGE MASTER LOGS нічого не дасть. У загальному випадку для вирішення цієї проблеми потрібно доручити управління двійковими журналами самому сервера MySQL, вже він щось не заплутається.
Необхідно виробити стратегію видалення старих журналів - за допомогою параметра expire_logs_days або іншими засобами, - інакше рано чи пізно MySQL заповнить двійковими журналами весь диск. При цьому слід враховувати і прийняту в організації політику резервного копіювання. Додаткову інформацію про довічним журналі см. В розділі «Формат довічного журналу» на стор. 601.