Сервер нон-стоп!Как мигрировать данные

Пример переноса данных

Адрес статьи:blog.Park Ruiqing.com/2019/10/27/…

предисловие

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

Далее в этой статье речь пойдет о том, как перенести данные без остановки.

кейс

В системе заказов есть такой набор столов заказов:

База данных: MySQL

Имя таблицы: order_{0~19}, где {0~19} — суффикс, всего 20 таблиц.

Первичный ключ: order_id, идентификатор заказа, полученный по алгоритму снежинки, время создания можно получить по идентификатору.

Исходная стратегия разделения таблицы: order_id % 20

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

Требовать:

1. Перенесите исходные данные 20 подтаблиц в новую таблицу.
2. В течение всего процесса миграции не допускается простоев, а внешнему миру должны предоставляться полные услуги.
3. Обеспечьте полную резервную схему, данные, сгенерированные в процессе миграции, не могут быть потеряны и не могут быть изменены вручную.

анализировать

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

Проанализируйте исходную таблицу данных: данные заказа обязательно будут увеличиваться со временем и объемом бизнеса, а фиксированное количество подтаблиц приведет к падению производительности по мере увеличения объема данных, поэтому после переноса данных количество подтаблиц не может быть исправлено, даже если изменение 20 на 100 однажды достигнет узкого места.

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

Анализ плана миграции

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

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

2. Уровень подключения: Это усовершенствованная версия схемы 1. Перехватывает SQL для двойной записи на уровне подключения, который отделен от бизнеса, но имеет ту же проблему, что и 1: цикл длинный, и необходимо убедиться, что старые данные не будут изменены перед миграцией.

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

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

5. Замаскированная подчиненная библиотека: По сравнению со схемой 4 преимущество в том, что нет необходимости читать лог напрямую, что решает проблему, заключающуюся в том, что БД неудобно читать лог напрямую в облаке.

Для сравнения, оба варианта 4 и 5 являются необязательными, поскольку база данных находится в облаке, читать журналы напрямую неудобно, а вариант 5 имеет зрелое промежуточное ПО с открытым исходным кодом**.canal**Доступно, поэтому автор выбрал вариант 5.

Адрес документа канала:GitHub.com/Alibaba/Misery…

Анализ резервного плана

После того, как новый код появится в сети, никто не может гарантировать его 100% правильность.Если миграция не удалась, ее необходимо откатить.Поэтому необходимо обеспечить синхронизацию исходных данных и новых данных.

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

Общий дизайн схемы

Резервное копирование исходных данных

1. воплощать в жизньflush logs: Создать новый бинлог, отсюда начнется восстановление данных.
2. Резервная таблица данных (order_{0~19}): Скопируйте исходную (старую) таблицу данных из основной базы данных A в резервную базу данных B.

восстановить и синхронизировать данные

1. Создайте достаточное количество новых таблиц в основной базе данных A, прикажите, чтобы новые таблицы были разделены по месяцам.
2. Напишите сценарий для чтения таблицы заказов из резервной базы данных B и записи новой таблицы заказов из основной базы данных A.
3. Начните синхронизацию данных старой таблицы с новой таблицей через канал с именем [процесс синхронизации-a].

онлайн

1. Скомпилируйте новый код и откройте новый кластер, подтвердите, что полная загрузка завершена.
2. воплощать в жизньflush logsСоздайте новый бинлог, и отсюда начнется синхронизация данных из новой таблицы в старую.
3. Трафик переключается на новый кластер.
4. Остановить [процесс синхронизации -a].
5. Запустите синхронизацию данных из новой таблицы со старой таблицей.

возвращаться

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

Эпилог

• flash logsПеред резервным копированием исходной таблицы данных, даже если в середине есть небольшой интервал времени, это не повлияет на итоговую согласованность данных (прослушивание бинлога всегда корректно).
• Данные бесценны, поэтому действуйте осторожно.

Если эта статья была вам полезна, ставьте лайк (￣▽￣)"

Рекомендуемое чтение

• Практика открытия шлюза API (1) — проектирование шлюза API
• Практика Open API Gateway (2) — Повтор атаки и защита
• Практика Open API Gateway (3) — Текущее ограничение
• Kubernetes (1) Следуйте официальной документации, чтобы собрать K8S с нуля.
• Развертывание приложений Kubernetes (2)
• Kubernetes (3) Как получить доступ к сервисам извне

Добро пожаловать в публичный аккаунт (код как поэзия)