Бесшовная миграция MySQL 5.0 -> Percona Server 5.5 с переразбивкой хранилища

    Здравствуйте.

    Хочу поделиться опытом миграции боевой базы данных с 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, поднимать на получившемся слепке сервер, и снимать с него мастер-дамп.

    Итак, ингредиенты


    • Два старых боевых MySQL-5.0-сервера под нагрузкой. Назовем их 5.0-master и 5.0-slave.
    • Два новых боевых Percona-5.5-сервера пока без нагрузки, данных и репликации. Назовем их 5.5-master и 5.5-slave.
    • Один промежуточный MySQL-5.0-сервер для снятия дампа. Назовем его 5.0-Kenny.

    Для разбиения InnoDB-хранилища по таблицам на новых серверах надо выставить опцию "innodb_file_per_table=1".

    Поскольку речь идет об облаке, мы играючи поднимаем три недостающих сервера за пять минут.

    В рамках программы по сокращению времени простоя до минимума мы решили не перенастраивать приложения для работы с новым мастером, а просто поднять ip старого мастера на новом сервере. Для этого необходимо, чтобы ip старого сервера был виден на новом мастере для всех клиентов. В нашем случае все пять серверов находятся в одной подсети, так что проблем с этим нет.

    А теперь — последовательность действий


    • С мастер-базы (5.0-master) снимаем дамп при помощи xtrabackup:

      innobackupex --user=root --password=Yoo0edae _каталог_назначения_
      

      Важно помнить, что чем больший объем данных вашей базы находится в MyISAM-таблицах, тем на большее время база будет заблокирована при финализации xtrabackup, так как MyISAM-таблицы копируются полностью во время финальной блокировки базы. В нашем случае MyISAM-данных практически нет, поэтому база находится в заблокированном состоянии всего несколько секунд.
    • В полученном каталоге с данными есть файл "xtrabackup_binlog_info" — запоминаем из него позицию в бинлоге.
    • Полученный слепок копируем на 5.0-Kenny (мы монтировали диск с Kenny по NFS на 5.0-Master, и указывали его в каталоге назначения при снятии данных xtrabackup-ом, так что данные на 5.0-Kenny появлялись в процессе работы xtrabackup). Там его подготавливаем:

      innobackupex --apply-log _каталог_с_бэкапом_
      

    • Останавливаем MySQL. вычищаем каталог с данными MySQL, в него копируем наш слепок:

      innobackupex --copy-back _каталог_с_бэкапом_
      

      Можно скопировать вручную. Тогда в MySQL-хранилище останется некоторый мусор от процесса резервирования. При необходимости выставляем правильного владельца на каталог с данными.
    • Запускаем MySQL. Убеждаемся, что ошибок нет.
    • С 5.0-Kenny снимаем дамп:

      mysqldump --all-databases > mysql.dump
      

    • Полученный дамп копируем на 5.5-master. Вливаем:

      mysql < mysql.dump
      

    • Рестартуем MySQL. Любуемся на гору ошибок в логе. Апгрейдим схему до версии 5.5:

      mysql_upgrade --force
      

    • Рестартуем MySQL. В логах должно быть чисто.
    • Включаем репликацию, подключаем 5.5-master к бинлогу 5.0-master. Для этого сначала добавляем на 5.0-master пользователя для репликации (про server-id все ведь помнят, да?):

      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 STATUS\G
      

      Наш 5.5-master какое-то время будет слейвом для 5.0-master. Для того чтобы запросы с 5.0-master попадали в бинлог на 5.5-master, на 5.5-master надо выставить опцию "log-slave-updates=1". По дефолту она равна нулю, то есть в бинлог попадают только локальные изменения.
    • Снимаем с 5.5-master дамп при помощи xtrabackup. Копируем дамп на 5.5-slave.
    • Поднимаем 5.5-slave, цепляем его к бинлогу 5.5-master.

    Итого, у нас получается четыре сервера: два старых, но пока боевых MySQL 5.0, и два новых Percona 5.5 уже с актуальными данными.

    • Переключаем всю read-only-нагрузку со старого 5.0-slave на новый 5.5-slave. Поскольку 5.5-slave реплицируется с 5.5-master, который в свою очередь реплицируется с 5.0-master, никто ничего не замечает. Полдела сделано — часть нагрузки у нас уже на новой связке.

    Начинается самое интересное. Переключаем master. Здесь находится точка невозврата. Начиная с этого момента, засекаем время простоя мастер-базы.

    • Останавливаем MySQL на 5.0-master.
    • Убеждаемся, что все данные из бинлога попали на 5.5-master
    • Отлучаем 5.5-master от бинлога:

      mysql> RESET SLAVE ALL;
      

    • Останавливаем MySQL на 5.5-master
    • На 5.0-master кладем сетевой интерфейс, по которому происходило общение приложений с базой, поднимаем этот ip на сервере, на котором у нас находится 5.5-master.
    • Убеждаемся, что arp-таблица обновилась.
    • Поднимаем 5.5-master. Убеждаемся, что MySQL слушает на новом ip.
    • Перезапускаем приложения, использующие persistent-connect к базе.

    Все


    В нашем случае время простоя было около полутора минут. Бóльшую часть этого времени складывался 5.0-master. В принципе, можно было время простоя уменьшить еще сильнее, сбросив InnoDB-кэши перед остановкой баз.

    vCloud показал себя с хорошей стороны. Производительность при переезде ощутимо выросла благодаря более мощному железу и значительно более шустрой дисковой подсистеме, так как виртуальный диск «размазан» по большому количеству физических носителей.
    Alawar Entertainment
    Company
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 9

      0
      А кроме хороших сторон, у VCloud каки-либо негативные особенности есть?
        0
        Ну vCloud — это всего лишь инструмент. В основе его лежит тот же ESXi-гипервизор. Если администраторы облака зажмут ресурсы, и нагонят туда клиентов — виртуалки начнут драться за ресурсы со всеми вытекающими последствиями. Негативные особенности — как у любой технологии виртуализации.

        Лично мне в vCloud больше всего не нравится куцая админка на flash и глючная консоль, не поддерживающая ни один современный браузер.
        0
        Из того с чем сталкивался — достаточно медленный и не самый удобный механизм экспорта виртуалок
          +1
          2 года назад наш сотрудник описывал nonstop HOWTO по переходу на innodb_file_per_table

          + линейная репликация даст 0 простой 5.0-master -> 5.5-master/slave -> 5.5-slave, в определенный момент переключаем с 5.0 на 5.5 мастер.
            0
            хорошо, только картинку з перемещениями добавьте пожулайста для наглядности кто-кому-когда-мастер-и-слейв.
              0
              Спасибо! Картинку добавил.
              0
              Интересное решение. Как сталкивались с похожим = пришлось использовать заглушку:)
                0
                А какой именно провайдер vCloud используется?

              Only users with full accounts can post comments. Log in, please.