Використання Innobackupex (Xtrabuckup) для бекапу MySQL

Mysqldump буде влаштовувати вас лише до того моменту, доки він зможе знімати дамп на протязі прийнятного часу. База збільшується і це саме час задуматись про альтернативи. І такою альтернативою може бути Xtrabackup.

Xtrabackup - розробка компанії Percona, програма, що дозволяє робити бекап MySQL-серверів і не блокує базу данних на протязі бекапу. Xtrabackup може працювати з InnoDB, XtraDB і MyISAM (проте з певними обмеження на кшталт інкрементальних бакапів) таблицями. Мабуть, головною особливістю Xtrabackup є його висока швидкість роботи, на відміну від Mysqldump-а, що пояснюється тим, що він працює на бінарному рівні (умовно кажучи, копіює бінарні файли /var/lib/mysql, а не генерує запити як mysqldump).

Для початку я б хотів би розповісти логіку роботи програми Xtrabackup (точніше як я її розумію) і почну саме з особливостей роботи InnoDB. Запити, що генерують користувачі, приходять на mysql-server, записуються у лог транзакцій (mysql bin log) а потім виконуються. Результати запитів одразу не пишуться на жорсткий диск і лишаються в кешах.

У випадку падіння демону Mysql (причин насправді може бути купа), то при наступному старті почнеться відновлення останніх операцій із бін-логу і таким чином база лишиться неушкодженою.

MySQL/InnoDB one file per table

Після видалення бази данних чи таблиці MySQL розмір файлу ibdata1 не змінюється, що в результаті може призвести до повного заповнення диску. Для вирішення цієї проблеми існує опція innodb_file_per_table, що дозволяє зберігати кожну таблицю в окремому файлі на відміну від стандартної поведінки зберігання таблиць. Як наслідок, при видаленні таблиці, видалиться файл, що відповідає за її вміст та звільниться простір на диску. Опція innodb_file_per_table увімкнена по замовчуванню в Mysql версії 5.6.6 і старше.

Щоб перейти до нового варіанту зберігання таблиць необхідно виконати декілька пунктів. Розглянемо варіант міграції всіх баз на новий метод їхнього зберігання. Перш за все, про всяк випадок, забекапимо всю директорію /var/lib/mysql:

# cd ~
# mkdir backup
# cd backup
# service mysql stop
# cp -ra /var/lib/mysql mysqldata_backup
# service mysql start

Зробимо дамп всіх існуючих баз:

# mysqldump --routines --events --flush-privileges --all-databases > all-db.sql

MySQL/Galera replication with Haproxy balancing

MySQL/Galera - синхронний мульти-майстер кластер для MySQL/InnoDB бази данних, що володіє такими перевагами:
- синхронна реплікація.
- аctive-active мульти-майстер топологія
- читання чи запис на будь-яку ноду кластеру.
- автоматичний контроль членів кластеру: проблемні члени будуть автоматично виключені з діючого кластеру.
- автоматичне (просте) додавання додаткових серверів до кластеру. Зручне масштабування.
- справжня паралельна реплікація, на рівні рядків.

Додам, що звичайна реплікація типу master-master не є синхронною. На активному майстрі всі запити спочатку будуть записані в binlog і лише потім будуть передані на інший пасивний MySQL-майстер (слейв), запити на пасивному сервері можуть виконуватись із значною затримкою. У випадку із Galera запити на кожній ноді виконуються одночасно, або майже одночасно.

MySQL/Galera кластер використовує бібліотеку Galera для реалізації реплікації, що працює через MySQL wsrep API (патчена версія MySQL)

Як я вже згадував Galera допускає запис на будь-яку ноду кластеру, навіть одночасні записи із різних нод в одну таблицю. Все це завдяки алгоритму сертифікації транзакцій:

Логіка алгоритму сертифікації приблизно така: SQL-запити приходить на різні сервери кластеру і якщо вони конфліктують між собою (наприклад, запис в той самий рядок таблиці) відбувається роллбек і послідовне виконання запитів (виправте, якщо я помиляюсь).

MySQL Sandbox (декілька MySQL-демонів різних версій на одному хості)

Продовжуємо розгляд установки декількох mysql-демонів на одному хості. Цього разу мова піде про Mysql Sandbox.

Mysql Sandbox - це набір скриптів на Perl для автоматизації та швидкого розвертання інстансів MySQL: за допомогою нього можна лиш однією командою підняти одночасно декілька mysql-демонів різних версій,  налаштувати реплікацію різних типів тощо. Причому установка додаткових інстансів не зачіпає директорій оригінального mysql, якщо він присутній на сервері. Насправді дуже корисно мати такий інструмент для тестування нових фіч чи для перевірки поведінки реплікації при певних діях.

Для початку завантажимо tar-архів mysql необхідної версії:

# wget -O mysql-5.6.11-linux-glibc2.5-x86_64.tar.gz http://www.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.11-linux-glibc2.5-x86_64.tar.gz/from/http://cdn.mysql.com/

Тепер переходимо до самого завантаження Mysql Sandbox:

# wget https://launchpad.net/mysql-sandbox/mysql-sandbox-3/mysql-sandbox-3/+download/MySQL-Sandbox-3.0.33.tar.gz

Розпаковуємо і переходимо в директорію:

# tar xvfz MySQL-Sandbox-3.0.33.tar.gz

# cd MySQL-Sandbox-3.0.33

І тепер власне потрібно визначитись з користувачем від якого будуть працювати mysql-інстанси. Це може бути рут чи звичайний користувач (на ваш вибір). Для рута виконуємо наступне:

# export SANDBOX_AS_ROOT=1

Mysqld_multi: декілька демонів mysql на одному хості

Іноді постає необхідність встановити ще одну базу даних на тому ж хості, але просто на іншому порту. І як показала практика, краще за все це робити за допомогою функціоналу mysqld_multi, котрим володіють останні версії mysql.

1) Ясна справа у вас має бути встановлений mysql-server та mysql-client.

2) Зупиняємо наявний демон, якщо його запущено, бекапимо конфіг /etc/mysql/my.cnf (чи просто /etc/my.cnf).

3) Створюємо новий:

cat /etc/my.cnf

[mysqld_multi]

mysqld = /usr/bin/mysqld_safe

mysqladmin = /usr/bin/mysqladmin

[mysqld1]

datadir = /var/lib/mysql1

socket = /var/lib/mysql1/mysql.sock

pid-file = /var/run/mysqld/mysqld1.pid

user = mysql

port = 3306

log-error=/var/log/mysqld1.log

[mysqld2]

datadir=/var/lib/mysql2

socket=/var/lib/mysql2/mysql.sock

pid-file = /var/run/mysqld/mysqld2.pid

user=mysql

port = 3307

log-error=/var/log/mysqld2.log

[mysqld3]

datadir=/var/lib/mysql3

socket=/var/lib/mysql3/mysql.sock

pid-file = /var/run/mysqld/mysqld3.pid

user=mysql

port = 3308

log-error=/var/log/mysqld3.log

Налаштування MySQL-реплікації типу Master - Master (Slave)

Власне налаштування  реплікації серверів баз даних - дуже важлива складова будь-якого High Load проекту. Надіюсь, що ця невеличка замітка допоможе комусь в освоєні даної теми,  або ж принаймні нагадає мені певні деталі з часом.  :)

Тож до справи!

Для початку опишимо певні деталі. Будемо вважати, що сервера мають такі айпі:

centos1 - 192.168.1.23
centos2 - 192.168.1.24

Редагуємо /etc/my.cnf сервера centos1. Додаємо до вже існуючих параметрів такі:

[mysqld]
# Номер сервера, що реплікується. У кожного має бути унікальний id.

server-id = 1

# Конфігурація сервера, як майстра. Указуємо, де будуть зберігатись бінлоги. 
# Бінлог - це список SQL-запитів (окрім SELECT та SHOW запитів ), що були виконані на сервері задля подальшої їх передачі на слейв.

log-bin = /var/lib/mysql/mysql-bin

# Конфігурація сервера, як слейва. Relay-log - лог дій, котрі були виконані на слейві за ініціативи майстра.
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
#База, що буде реплікуватись.
replicate-do-db = dbwordpress

Для сервера centos2 необхідно прописати ідентичні параметри, окрім значення 'server-id' (змініть цифру наприклад на 2).
Рестартуємо mysql на кожному сервері.