- PVSM.RU - https://www.pvsm.ru -
Здравствуйте.
Хочу поделиться опытом миграции боевой базы данных с MySQL 5.0 на Percona Server 5.5 под нагрузкой почти без отрыва от производства.
База у нас древняя, пережила несколько апгрейдов MySQL. Начинали с MySQL 3.x. С ростом нагрузки, уже на MySQL 5.0, настроили репликацию и подключили еще один сервер для чтения. Тогда мы это делали стандартными средствами MySQL, без привлечения xtrabackup — полностью блокировали сервер на время создания мастер-дампа и вывешивали на сайтах заглушки.
Затем встала следующая проблема — на томе с данными стало заканчиваться место. Плюс InnoDB-хранилище исторически располагалось в одном файле. Было рассмотрено много вариантов решения. Начиная от размещения базы на iSCSI-томе и заканчивая перетыканием в рейд более емких дисков, расширением на них volume group / logical volume с последующим расширением файловой системы.
В качестве временного варианта решили подключить iSCSI-том из виртуалки под VMWare vCloud (не реклама, честно!). vCloud стоит у нас под боком.
Начали с эксперимента на slave. Эксперимент прошел удачно, и какое-то время второй read-only MySQL держал хранилище на iSCSI-томе.
В качестве эксперимента подключили вторым слейвом на чтение сервер в vCloud. Перенесли на него всю нагрузку с первого слейва. По производительности виртуальный сервер выигрывал с хорошим отрывом. Сказывалось более мощное железо у хостов vCloud. Переключили нагрузку назад. Стали думать.
В этот момент случилось странное мистическое событие. Спустя нескольких часов после завершения эксперимента с нагрузкой на виртуальном сервере в датацентре произошла хитрая авария, в результате которой обесточилось несколько серверов, в том числе физический слейв. В relay log, находящийся на iSCSI-томе у физического слейва, попал мусор. Репликация остановилась.
Самым логичным действием в этой ситуации было переключение на облачный слейв, что мы и сделали.
Таким образом мы уже находились одной read-only ногой в vCloud. Надо было перетаскивать master.
Переехать решили на Percona 5.5, так же на два сервера, но с потабличным разбиением InnoDB-хранилища.
Основным ограничением при переезде была невозможность останавливать базу на сколько-нибудь продолжительное время.
Поскольку речь идет о разбиении InnoDB-хранилища на таблицы, простым копированием данных обойтись не получится. Надо вливать новую базу из дампа.
Чтобы получить мастер-дамп, надо залочить 125-гиговую базу на время более часа. Это неприемлемо на боевой базе. Мы решили бэкапить мастер при помощи xtrabackup, поднимать на получившемся слепке сервер, и снимать с него мастер-дамп.
Для разбиения InnoDB-хранилища по таблицам на новых серверах надо выставить опцию "innodb_file_per_table=1".
Поскольку речь идет об облаке, мы играючи поднимаем три недостающих сервера за пять минут.
В рамках программы по сокращению времени простоя до минимума мы решили не перенастраивать приложения для работы с новым мастером, а просто поднять ip старого мастера на новом сервере. Для этого необходимо, чтобы ip старого сервера был виден на новом мастере для всех клиентов. В нашем случае все пять серверов находятся в одной подсети, так что проблем с этим нет.
innobackupex --user=root --password=Yoo0edae _каталог_назначения_
Важно помнить, что чем больший объем данных вашей базы находится в MyISAM-таблицах, тем на большее время база будет заблокирована при финализации xtrabackup, так как MyISAM-таблицы копируются полностью во время финальной блокировки базы. В нашем случае MyISAM-данных практически нет, поэтому база находится в заблокированном состоянии всего несколько секунд.
innobackupex --apply-log _каталог_с_бэкапом_
innobackupex --copy-back _каталог_с_бэкапом_
Можно скопировать вручную. Тогда в MySQL-хранилище останется некоторый мусор от процесса резервирования. При необходимости выставляем правильного владельца на каталог с данными.
mysqldump --all-databases > mysql.dump
mysql < mysql.dump
mysql_upgrade --force
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl_master_55' IDENTIFIED BY 'slavepass';
mysql> FLUSH PRIVILEGES;
после чего на 5.5-master выполняем запрос:
mysql> CHANGE MASTER TO MASTER_HOST='master_host_name', MASTER_USER='repl_master_55',
MASTER_PASSWORD='slavepass', MASTER_LOG_FILE='recorded_log_file_name', MASTER_LOG_POS=recorded_log_position;
mysql> START SLAVE;
Значения MASTER_LOG_FILE и MASTER_LOG_POS берем из файла "xtrabackup_binlog_info".
mysql> SHOW SLAVE STATUSG
Наш 5.5-master какое-то время будет слейвом для 5.0-master. Для того чтобы запросы с 5.0-master попадали в бинлог на 5.5-master, на 5.5-master надо выставить опцию "log-slave-updates=1". По дефолту она равна нулю, то есть в бинлог попадают только локальные изменения.
Итого, у нас получается четыре сервера: два старых, но пока боевых MySQL 5.0, и два новых Percona 5.5 уже с актуальными данными.
Начинается самое интересное. Здесь находится точка невозврата. Начиная с этого момента, засекаем время простоя мастер-базы.
mysql> RESET SLAVE ALL;
В нашем случае время простоя было около полутора минут. Бóльшую часть этого времени складывался 5.0-master. В принципе, можно было время простоя уменьшить еще сильнее, сбросив InnoDB-кэши перед остановкой баз.
vCloud показал себя с хорошей стороны. Производительность при переезде ощутимо выросла благодаря более мощному железу и значительно более шустрой дисковой подсистеме, так как виртуальный диск «размазан» по большому количеству физических носителей.
Автор: winduzoid
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/mysql/17027
Ссылки в тексте:
[1] подготавливаем: http://www.percona.com/doc/percona-xtrabackup/howtos/recipes_ibkx_local.html
[2] server-id: http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_server_id
Нажмите здесь для печати.