Мышление и краткое изложение схемы миграции базы данных

об авторе

Лэй Сяолун

Кунар, администратор баз данных

Присоединился к Qunar в августе 2019 г. Имеет богатый опыт эксплуатации, обслуживания и оптимизации баз данных.Сейчас он отвечает за эксплуатацию и обслуживание MySQL/Redis в компании, а также за внедрение и внедрение решений по автоматизации.

1 Обзор

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

2. План миграции

В целом дизайн сценариев миграции данных, в зависимости от исходной структуры данных и деловой сцены. Конечная цель - для бизнеса, насколько это возможно, прекратить делать более короткие, тем лучше, даже не остановка, но также необходимо обеспечить согласованность данных.

2.1 Вариант 1

Обычный метод онлайн-миграции данных заключается в том, чтобы сначала установить ведущий-ведомый и синхронизировать данные, дождаться переключения в период низкой пиковой нагрузки.Основной процесс выглядит следующим образом:

Новый и старый кластеры выполняют репликацию master-slave для синхронизации данных.
Прекратите деловую переписку в непиковые часы и проверьте согласованность данных синхронизации master-slave.
Модификации бизнеса подключаются к новым кластерам, публикуют программы
Проверка результатов миграции

Преимущества и недостатки вышеуказанных методов очевидны.

** Преимущества: ** Архитектура проста, очень удобна для администраторов баз данных, нужно только создать новый набор кластеров, гарантируя, что мастер может быть согласованным с синхронизацией и данными.

** Недостатки: ** Это не удобно для бизнеса и требует прекращения записи в период низких пиковых нагрузок; если в кластере много бизнеса, сервер должен быть остановлен одновременно, и изменение метода подключения должен быть освобожден, он также может столкнуться с тем, что переключение трафика не завершено, что приводит к ситуации двойной записи.

2.2 Вариант 2

Миграция данных с помощью прокси-сервера, конкретный процесс выглядит следующим образом:

Делится на три этапа:

Установите репликацию master-slave для репликации данных исходного кластера в новый кластер.
В исходном кластере плюс один прокси, для переадресации трафика, через прокси для управления распределением потока в какой кластер; на этот раз уведомление о развитии бизнеса, изменение подключения к прокси (подключение может быть виртуальным IP, доменным именем, именем службы , и т.д.).
Далее идет работа администратора баз данных, наблюдайте за трафиком, и трафик трафика режется на прокси, отрезается от исходного к целевому мастер-подчиненному экземпляру, проверяется согласованность данных, используется агент для проигрывания трафика в целевую базу данных. Следует отметить, что при резке стока и обрыва гарантийный срок достаточно мал, а репликация не задерживается. Наконец, прокси, окончательная программа напрямую обращается к базе данных назначения, переключая виртуальный IP-адрес или изменяя разрешение DNS и т. д. Или уведомите компанию об изменении метода подключения с прокси-сервера на целевую базу данных.

Кратко опишите преимущества и недостатки плана миграции.

**Преимущество.** Преимущество этого решения заключается в том, что после добавления прокси администратор базы данных может контролировать распределение входящего трафика. Когда разработчик публикует программу для изменения метода подключения, она поддерживает скользящую публикацию, и два метода доступа сосуществуют, и нет необходимости останавливать службу; с другой стороны, работа администратора баз данных и разработки не связаны, и существует нет необходимости публиковать программу в фиксированное время, выполнять переход и администратор базы данных. Вы можете использовать источник трафика, чтобы определить, каким образом бизнес получает доступ к базе данных, чтобы обеспечить чистоту трафика.

**Недостатки.** Архитектура относительно сложна, что увеличивает стоимость и сложность эксплуатации и обслуживания для администраторов баз данных. Время прерывания службы зависит от времени перезапуска прокси, то есть времени прерывания для переключения трафика с исходного кластера на целевой кластер, но обычно оно очень быстрое и может контролироваться в течение секунд. Соединение с базой данных будет прервано, и необходимо обеспечить возможность повторного подключения бизнеса, и в то же время должна быть обеспечена непротиворечивость данных master-slave.

2.3 Резюме

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

Почему здесь доверие выделено жирным шрифтом? В нем должна быть история. Как упоминалось ранее, бизнес должен завершить изменение режима подключения в течение определенного времени, от изменения адреса старого кластера до доступа к новому кластеру. Правильно ли коммутируется трафик или нет, полностью зависит от бизнес-стороны. В период отключения администратор базы данных не может судить о том, правильно ли коммутируется бизнес-трафик и есть ли какой-либо остаточный трафик, записанный в старом кластере. определяется после открытия бизнеса. Если трафик не резать начисто, будет поздно, бизнес начнет дублировать запись, а данные будут неконсистентными, думайте, как откатить или дополнить данные. Однако для администраторов баз данных с «схемированием» они могут не так сильно доверять бизнесу, и они тихо оставят его позади.Установив старый кластер в режим только для чтения, восстановив права пользователей и т. д., бизнес больше не сможет писать в старый кластер. Для обеспечения согласованности данных при потере бизнеса преимущества второго решения весьма очевидны.

Основная идея второго решения состоит в том, чтобы позволить базе данных предоставлять два метода доступа одновременно, и два метода доступа одновременно указывают на экземпляр базы данных, чтобы бизнес мог плавно переходить между двумя методами. . Развитие бизнеса и работа администратора баз данных отделены друг от друга, и времени для публикации программ достаточно. У администраторов баз данных также есть соответствующие средства для оценки полноты бизнес-трафика и обеспечения согласованности данных.

3. Кластерная архитектура Qunar

Основываясь на идее второй приведенной выше схемы, ниже представлена схема обновления и миграции внутренней архитектуры Qunar. Давайте сначала разберемся с архитектурой базы данных, куда идти.

3.1 Кластер МММ

Схема архитектуры кластера выглядит следующим образом:

MMM (менеджер репликации Master-Master для MySQL) — это относительно старая архитектура высокой доступности базы данных, которая в первые дни широко использовалась в Qunar. Контролируйте и управляйте двунаправленной репликацией MySQL с помощью монитора и агента. Бизнесу разрешено одновременно писать только на один мастер, а другой альтернативный мастер предоставляет только услуги чтения.Подчиненные узлы также могут быть добавлены для балансировки нагрузки чтения, а виртуальные IP-адреса используются для предоставления внешних услуг без ограничений со стороны клиент.

Отказоустойчивость, реализованная MMM, использует метод дрейфа VIP.Поскольку он использует асинхронную репликацию, он не может полностью гарантировать согласованность данных.Поэтому он подходит для сценариев, где требования к согласованности данных не очень высоки, но вы хотите обеспечить бизнес-доступность для наибольшей степени. Для тех служб, которые требуют высокой согласованности данных, MMM не рекомендуется для архитектуры высокой доступности, а MMM не поддерживает разделение сети и не может быть развернуто в компьютерных залах.

Для получения подробной информации перейдите на официальный сайт:mysql-mmm.org

3.2 Кластер PXC

Percona XtraDB Cluster (сокращенно PXC) — это решение Percona с открытым исходным кодом для обеспечения высокой доступности MySQL. Он интегрирует Percona Server и Percona XtraBackup с библиотекой Galera для синхронной репликации с несколькими мастерами. По сравнению с традиционной асинхронной репликацией MySQL, она может обеспечить сильную согласованность данных, и состояние данных на любом узле в кластере в любое время полностью согласовано, и вся архитектура децентрализована, и все узлы являются одноранговыми, что позволяет запись и чтение на любом узле, а кластер будет синхронизировать состояние данных со всеми остальными узлами. Однако в настоящее время кластер PXC имеет много ограничений в использовании, таких как: поддерживается только механизм хранения InnoDB, ограничение размера транзакции и т. д., вам необходимо выбрать соответствующий сценарий приложения.

Для получения подробной информации перейдите на официальный сайт:Woohoo.Чай пуэр,ох уж.com/doc/чай пуэр,ох уж...

Внутренняя архитектура Qunar выглядит следующим образом:

Кластер PXC, используемый внутри Qunar, обычно состоит из трех узлов.Хотя PXC поддерживает многоточечную запись, многоточечная запись может легко привести к конфликтам данных, что вызовет большие дополнительные накладные расходы и повлияет на производительность.Поэтому в производственной среде мы по-прежнему используйте только один узел для записи, а два других узла предоставляют услуги чтения; только когда узел записи переключается, допускается короткая многоточечная запись, чтобы обеспечить плавный переход бизнеса на новый узел записи. Коммутация высокой доступности PXC отличается от традиционной коммутации ведущий-ведомый, и предприятиям больше не нужно терпеть кратковременные прерывания базы данных только для чтения и флэш-памяти. Внешние службы предоставляются в виде имен служб пространства имен, получаются реальный IP-адрес и порт узлов кластера баз данных, экранированных бизнес-уровнем.Клиент получает информацию о топологии кластера через центр конфигурации.

Sentinels: Кластер Sentinels, используемый для мониторинга рабочего состояния и информации о топологии кластера PXC, аналогичный кластеру Sentinels Redis, который решает одноточечную проблему MMM Monitor; при изменении топологии кластера Sentinel изменит Центр конфигурации и переход в автономный режим узла сбоя, обновление главного узла и другие операции; В то же время измените информацию о версии zookeeper, запустите клиента для восстановления соединения и повторного получения информации о конфигурации кластера.
Сервер конфигурации: Центр конфигурации кластера также представляет собой набор кластеров PXC, которые используются для хранения информации о пространстве имен и узлах кластера (включая IP-адрес, порт, роли чтения и записи, онлайн или нет, информацию об изменениях и т. д. ).

4. Миграция кластера Qunar 4.1 МММ Миграция PXC

В силу исторических причин в базе данных Qunar до сих пор много кластеров архитектуры МММ.Некоторые важные «наследственные» бизнесы до сих пор работают на МММ, неся большие риски, а тем, у кого никогда не было проблем, можно сказать «удачи». .". Во-первых, администраторам баз данных было сложно продвигать миграцию бизнес-архитектуры.Во-первых, архитектура PXC редко использовалась в отрасли и не имела достаточного понимания, поэтому не было уверенности.Во-вторых, сервисы были старыми и имели большое значение, и они не осмеливались легко изменить их.

После многих лет практического тестирования qunar архитектура PXC была оказана превосходной базой данных с высокой доступностью. Бизнес-сторона начала иметь определенную степень доверия. В сочетании с воздействием эпидемии в этом году мы начали «практиковать внутреннюю силу». Воспользовавшись этой возможностью, Департамент DBA реализовал план Миграции в Архитектуре MMM PXC для компании.

Такой огромный проект требует комплексного решения, которое в первую очередь должно иметь следующие пункты:

Удобное для бизнеса, круглосуточное обслуживание, поддержка непрерывного выпуска
Поддержка отката: если в бизнес-релизе обнаружены проблемы с работой на архитектуре PXC, его можно откатить в любое время.
Цикл миграции длительный, и весь процесс должен обеспечивать высокую доступность.
Нет ограничений по времени для бизнес-релиза и фиксированного периода окна.

Исходя из вышеперечисленных пунктов, первое решение не может быть удовлетворено, так как в старом сервисе серьезное переиспользование базы данных, нет возможности полностью модифицировать адрес за один раз, а смириться с длительной приостановкой работы нельзя. услуга. Второе решение - добавить слой прокси, прописать ip и порт прокси в центре конфигурации PXC, и бизнес можно публиковать в пространство имен.По сути, старый кластер по-прежнему доступен через прокси, а направление трафика фактически контролируется прокси-сервером, а центр конфигурации поддерживает модификации, инициируемые человеком.

Таким образом, кажется, что вышеуказанные требования могут быть удовлетворены. Но проблема также очевидна: администратору баз данных необходимо поддерживать дополнительный набор прокси и обеспечивать их высокую доступность. Кроме того, будет добавлено много ресурсов.Мигрировать нужно более 120 наборов кластеров MMM.Стоимость обслуживания и ресурсы можно себе представить.

Основываясь на приведенной выше идее миграции и особенностях пространства имен, мы, наконец, выбрали схему обновления на месте и отказались от прокси-сервера. Общий процесс выглядит следующим образом:

1. Сначала используйте виртуальный IP-адрес MMM в качестве адреса доступа к кластеру PXC, зарегистрируйтесь в центре конфигурации и zookeeper и предоставьте пространство имен, которое можно использовать извне.

2. Уведомить бизнес о публикации в пространстве имен PXC; когда бизнес получает доступ к базе данных через пространство имен, доступ к узлу кластера MMM фактически осуществляется через VIP. Этот процесс поддерживает откат в любое время и поддерживает методы доступа к VIP и пространству имен. При высокой доступности для пространства имен нижним уровнем является VIP, который будет переключаться с высокой доступностью MMM, поэтому проблема единой точки отказа отсутствует.

3. Наблюдаем коммутацию бизнес-трафика, о чем можно судить по зк соединению.

4. После выпуска услуги обновите узлы до версии PXC один за другим и разверните Sentinel, чтобы завершить построение полного кластера PXC Процесс обновления выглядит следующим образом:

В качестве альтернативы, главный узел в автономном режиме MMM MASTER2, PXC обновляется до первого узла.

MASTER2 воссоединяется с кластером и восстанавливает параметры MMM, основная роль чтения, переключения ролей чтения и записи, узел MASTER2 на основной узел, внешние службы (узел, обслуживающий версию PXC, доступность MMM все еще действительна, вы можете наблюдать период времени , Если у бизнеса из-за ограничений PXC возникли проблемы совместимости, можно читать и писать, чтобы переключиться здесь, роль записи сокращается до исходной простой версии).

MMM отключает старый главный узел MASTER1 (в настоящее время он используется в качестве альтернативного главного узла) и обновляет его до узла PXC, используя MASTER2 в качестве донора для формирования 2-узлового кластера PXC (здесь высокая доступность Кластер МММ уничтожен, дальнейшие действия нужно делать последовательно).

MMM отключит оставшиеся ПОДЧИНЕННЫЕ узлы, обновит их до узлов PXC и присоединится к кластеру PXC, состоящему из MASTER1 и MASTER2; разверните дозорный кластер, измените виртуальный IP-адрес центра конфигурации на реальный IP-адрес, подтвердите, что виртуальный IP-адрес не имеет доступа к трафику и выйдите из VIP.

5. Измените версию zk и уведомите клиента о повторном подключении. На данный момент бизнес полностью переведен на архитектуру PXC.

6. Завершение работы, проверка задач мониторинга и резервного копирования.

Следует отметить в процессе миграции, что в процессе апгрейда узлов на PXC один за другим, после апгрейда на второй узел, высокая доступность МММ была разрушена, а высокая доступность PXC еще не сформировалась до развертывание Sentinel. Поэтому, когда дело доходит до этой связи, она должна выполняться быстро и последовательно.Мы используем автоматические обновления программы, чтобы обеспечить стандартизацию и эффективность работы, минимизировать время одноточечной операции и избежать ошибок. В крайних случаях вы также можете вручную привязать VIP, чтобы обеспечить доступность службы.

Вышеуказанная схема миграции прошла демонстрацию практикой и получила признание одноклассников. В настоящее время существует более 70% обновлений кластера МММ, и весь процесс реализует автоматизацию, хотя цикл миграции очень длительный, но на самом деле не требует слишком большого вмешательства человека.

4.2 Случай разделения миграции

Основываясь на идее обновления PXC на месте с помощью MMM, мы также можем работать со многими сценариями миграции. Сейчас у бизнеса возникла потребность в разбиении базы данных: Кластер А — это кластер МММ.Из-за большого количества БД выше, бизнес много перемешан, и трафик большой, и база данных перегружена. Теперь мы собираемся разделить более важный сервис, соответствующий определенной БД в инстансе, он должен работать независимо на новом кластере и должен поддерживать развертывание между машинами, а в силу специфики бизнеса , обслуживание не может быть прервано.

Ссылаясь на приведенные выше идеи миграции, давайте взглянем на диаграмму архитектуры миграции:

Исходный кластер представляет собой кластер MMM, который состоит из двух узлов, MASTER1 и MASTER2, а доступ к службам осуществляется через WVip и RVip соответственно. Теперь необходимо перенести бизнес А. Общий процесс работы выглядит следующим образом:

Узел записи кластера MMM, MASTER1 в качестве узла-донора кластера PXC, создает кластер PXC (при условии, что MASTER1 был обновлен с обычной версии MySQL до версии PXC).
Зарегистрируйте реальный IP-адрес MASTER1 в центре конфигурации; в настоящее время MASTER1 поддерживает доступ к пространству имен с использованием MMM-WVIP и PXC.
Бизнес, который необходимо перенести мигрирование, может быть сглажено из WVIP в пространство имен.
Кластер MMM OFFLINE MASTER1, Master1 отсоединен от кластера MMM (на данный момент MMM доступен только в предоставлении услуг. Для обеспечения доступности он может увеличиваться из библиотеки во избежание экстремальных ситуаций).

Перенесенный бизнес уже получил доступ к кластеру PXC, в то время как остальные службы по-прежнему обращаются к MMM.Последняя работа заключается в переводе MASTER1 в автономный режим из кластера PXC и восстановлении главного узла-кандидата MMM.

5. Резюме

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

В этой статье в основном описывается, что при использовании прокси-уровня один и тот же узел базы данных поддерживает два способа или два адреса для доступа к базе данных, так что бизнес-трафик может плавно переходить от старого метода подключения к новому методу подключения и реализовывать большую часть бизнеса. удобная схема миграции. Основываясь на этой идее, мы можем иметь дело с различными сценариями миграции без необходимости останавливать и отключать сервер, а также отделять работу разработчиков и администраторов баз данных, что значительно повышает эффективность работы.