Любой крупный проект начинался с пары серверов.
Сначала был один сервер БД, потом к нему добавили слейвы для масштабирования чтения.
И тогда – стоп! Хозяин один, а рабов много; если уйдет один из слейвов, то все будет хорошо, а если уйдет мастер, то будет плохо: даунтайм, админы пытаются поднять сервер.
Что делать? Забронируйте мастера.
Мой коллега Павел уже писал об этом статья , я не буду повторять.
Вместо этого я расскажу вам, почему вам обязательно нужен Orchestrator for MySQL! Начнем с главного вопроса: «Как мы переведем код на новую машину при уходе мастераЭ»
- Мне больше всего нравится схема с VIP (Виртуальным IP), о ней мы поговорим ниже.
Он самый простой и очевидный, хотя и имеет очевидное ограничение: мастер, который мы зарезервируем, должен находиться в сегменте L2 с новой машиной, то есть о втором DC можно забыть.
А, по-хорошему, если следовать правилу, что большой L2 — это зло, потому что L2 только на стойку, а L3 — между стойками, а такая схема имеет еще больше ограничений.
- Вы можете написать DNS-имя в коде и разрешить его через /etc/hosts. На самом деле никакого решения не будет. Преимущество схемы: нет ограничений, свойственных первому способу, то есть можно организовать перекрестный ДЦ.
Но тогда возникает очевидный вопрос: как быстро мы сможем доставить изменения в /etc/hosts через Puppet-Ansible?
- Второй способ можно немного изменить: установить на всех веб-серверах кеширующий DNS, через который код будет поступать в главную базу данных.
Вы можете установить TTL 60 для этой записи в DNS. Кажется, если правильно реализовать, метод хорош.
- Схема с обнаружением сервисов, подразумевающая использование Consul иetcd.
- Интересный вариант с ПроксиSQL .
Вам необходимо направить весь трафик в MySQL через ProxySQL; ProxySQL сам может определить, кто является мастером.
Кстати, об одном из вариантов использования этого продукта вы можете прочитать у меня.
статья .
Типичная схема инфраструктуры: 
Сразу опишу очевидные ситуации, которые необходимо учитывать:
- VIP-адрес не должен быть прописан в конфиге ни на одном из серверов.
Представим ситуацию: мастер перезагрузился, и пока он загружался, Оркестратор перешёл в отказоустойчивый режим и сделал одного из слейвов мастером; потом старый хозяин поднялся, и теперь ВИП на двух машинах.
Это плохо.
- Для оркестратора вам нужно будет написать скрипт для вызова старого мастера и нового мастера.
На старом мастере нужно запустить ifdown, а на новом мастере — ifup vip. Было бы неплохо еще включить в этот скрипт, что в случае аварийного переключения порт на старом мастер-свитче просто отключается, чтобы избежать какого-либо расщепления мозга.
- После того, как Оркестратор вызвал ваш сценарий, чтобы сначала удалить VIP и/или погасить порт на коммутаторе, а затем вызвал сценарий повышения VIP на новом ведущем устройстве, не забудьте использовать команду arping, чтобы сообщить всем, что новый VIP теперь здесь.
- Все подчиненные устройства должны иметь read_only=1, и как только вы повысите статус подчиненного устройства до главного, оно должно иметь read_only=0.
- Не забываем, что любой слейв, которого мы для этого выбрали, может стать мастером (в Оркестраторе есть целый механизм предпочтения, какой слейв рассматривать кандидатом на новый мастер в первую очередь, какой на втором месте, и какой слейв должен не быть выбранным вообще ни при каких обстоятельствах мастер).
Если слейв станет мастером, то на нем останется нагрузка слейва и прибавится нагрузка мастера, это надо учитывать.
- Orchestrator имеет очень удобный графический интерфейс, отображающий всю топологию (см.
скриншот ниже).
- Оркестратор может отслеживать, какие слейвы отстают, а где вообще сломалась репликация (у нас к Оркестратору прикреплены скрипты для отправки СМС).
- Оркестратор сообщает вам, у каких подчиненных устройств ошибочный GTID.
Что такое ошибка GTID? Для работы Orchestrator существует два основных требования:
- Необходимо, чтобы псевдо-GTID был включен на всех машинах кластера MySQL; у нас включен GTID.
- Необходимо, чтобы везде был один тип бинлогов, можно использовать оператор.
У нас была конфигурация, в которой у мастера и большинства слейвов был Row, а двое исторически оставались в смешанном режиме.
В результате Оркестратор просто не захотел подключать этих слейвов к новому мастеру.
Вы можете прочитать об этом больше здесь .
Таким образом, Orchestrator показывает вам через ошибочный GTID, что на ведомом устройстве есть транзакции, которых нет на ведущем.
Почему это происходит?
- Read_only=1 не включен на ведомом устройстве, кто-то подключился и выполнил запрос на изменение данных.
- Super_read_only=1 на слейве не включен, то админ, перепутав сервер, зашёл и выполнил там запрос.
- Если вы учли оба предыдущих пункта, то есть еще одна хитрость: в MySQL запрос на очистку бинлогов тоже идет в бинлог, поэтому при первой очистке на мастере и всех слейвах появится GTID errant. Как этого избежать? В Perona-5.7.25-28 введен параметр binlog_skip_flush_commands=1, который запрещает запись флеша в бинлоги.
На сайте mysql.com есть установленный ошибка .
Если вы пока не хотите использовать Orchestrator в режиме отработки отказа, переведите его в режим наблюдения.
Тогда у вас всегда будет перед глазами карта взаимодействия MySQL-машин и наглядная информация о том, какой тип репликации стоит на каждой машине, отстают ли слейвы, а главное, насколько они согласованы с мастером! Очевидный вопрос: «Как должен работать ОркестраторЭ» Он должен выбрать новый мастер из текущих слейвов, а затем переподключить к нему всех слейвов (для этого и нужен GTID; если использовать старый механизм с binlog_name и binlog_pos, то переключение слейва с текущего мастера на новый это просто невозможно!).
До того, как у нас появился Orchestrator, мне однажды приходилось делать все это вручную.
Старый мастер зависал из-за глючного контроллера Adaptec; у него было около 10 рабов.
Мне нужно было перенести VIP с мастера на один из слейвов и переподключить к нему все остальные слейвы.
Сколько консолей мне пришлось открыть, сколько одновременных команд я ввел.
Пришлось ждать до 3 часов ночи, снять нагрузку со всех слейвов, кроме двух, сделать из двух мастер-машину первую, сразу присоединить вторую машину к нему, поэтому подключите к новому мастеру все остальные подчиненные устройства и верните нагрузку.
В общем, ужас.
Как работает Orchestrator при переходе в режим аварийного переключения? Легче всего это проиллюстрировать на примере ситуации, когда мы хотим сделать мастер более мощной, более современной машиной, чем он есть сейчас.
На рисунке показана середина процесса.
Что уже сделано к этому моменту? Мы сказали, что хотим сделать каким-то слейвом новый мастер, Оркестратор стал просто переподключать к нему все остальные слейвы, причем новый мастер выступает в роли транзитной машины.
При такой схеме ошибок не возникает, все слейвы работают, Оркестратор удаляет ВИП со старого мастера, переносит на новый, делает read_only=0 и забывает про старый мастер.
Все! Даунтайм нашего сервиса – это время VIP-перевода, которое составляет 2-3 секунды.
На сегодня все, спасибо всем.
Скоро будет вторая статья об Orchestrator. В знаменитом советском фильме «Гараж» один персонаж сказал: «Я бы с ним в разведку не пошёл!» Так что, Оркестратор, я бы пошел с тобой на разведку! Теги: #*nix #Системное администрирование #MySQL #Orchestrator
-
Киберугрозы, Которые Ознаменуют 2011 Год
19 Oct, 24 -
Глобальное Антивирусное Тестирование
19 Oct, 24 -
Публикация Приложения В Android Market
19 Oct, 24 -
Кыргызстан Отключен От Интернета
19 Oct, 24 -
Экстремальная Оптимизация
19 Oct, 24
