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

задний план

В «Путешествии на Запад» Син Е есть очень известная строчка: «У меня когда-то было передо мной искреннее чувство, которое я не лелеял, и я сожалел о нем, когда потерял его. Самая болезненная вещь на свете , если Бог может дать мне шанс сделать это снова, я скажу три слова любой девушке: я люблю тебя, если мне придется добавить к этой любви крайний срок, я надеюсь, что это 10 000 лет!" разработчик В наших глазах это ощущение такое же, как и данные в нашей базе данных. Мы надеемся, что оно не изменится в течение 10 000 лет, но оно часто имеет неприятные последствия. При постоянном развитии компании и постоянном изменении бизнеса наши требования к данные также постоянно меняются. Изменения, вероятно, будут следующими:

Подбиблиотека и подтаблица: Развитие бизнеса становится все быстрее и быстрее, что приводит к все большему давлению на одномашинные базы данных и все большему объему данных.В настоящее время для решения этой проблемы обычно используется метод подбазы данных, а трафик база разбита на разные группы на машине. Из автономной базы данных в подбазу данных нам необходимо полностью перенести наши данные, чтобы мы могли успешно использовать наши данные в подбазе данных.
Замените носитель информации: Подбаза данных, описанная выше, вообще говоря, после миграции носитель данных остается прежним.Например, Mysql для одной машины использовался до, а после подбазы данных он становится Mysql для нескольких машин. В полях таблицы нашей базы данных ничего не изменилось, и миграция относительно проста. Иногда мы не можем решить все проблемы с помощью подбазы данных и подтаблицы.Если нам нужно много сложных запросов, использование Mysql может быть ненадежным решением в настоящее время, тогда нам нужно заменить носитель запроса, например например, с помощью elasticsearch, который будет немного сложнее, поскольку этот вид миграции будет включать преобразование данных между различными носителями.
Переключиться на новую систему: Как правило, при быстром развитии компаний будет много проектов, которые повторяются ради скорости.Когда у компании есть определенный период времени, эти проекты часто объединяются и становятся платформой или средней платформой. например, некоторые из наших членских систем, система электронной коммерции и т. д. В это время часто возникает проблема.Данные в старой системе необходимо перенести в новую систему, которая на данный момент более сложная.Возможно, что изменился не только носитель данных, но и язык проекта могут быть разные С точки зрения данных отделы могут быть разными, поэтому сложность этой миграции данных относительно высока, и риск также выше.

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

перенос данных

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

миграция стоковых данных

Прежде всего, давайте поговорим о том, как выполнить миграцию стоковых данных. После поиска в сообществе с открытым исходным кодом для переноса стоковых данных мы обнаружили, что нет очень полезных инструментов. В настоящее время DTS Alibaba Cloud обеспечивает миграцию стоковых данных, а DTS поддерживает изоморфизм и неоднородность, поддерживает миграцию между различными источниками данных и в основном поддерживает распространенные в отрасли базы данных, такие как Mysql, Oracle, SQL Server и т. д. DTS больше подходит для первых двух сценариев, о которых мы упоминали ранее. Один из них — сценарий подбазы данных. Если вы используете DRDS от Alibaba Cloud, вы можете напрямую перенести данные в DRDS через DTS. является Redis или ES, DTS поддерживает прямую миграцию.

Так как же работает стоковая миграция DTS? На самом деле, это относительно просто, это, вероятно, следующие шаги:

Когда запускается задача переноса запасов, мы получаем максимальный идентификатор и минимальный идентификатор, которые необходимо перенести.
Установите сегмент, например 10 000, и каждый раз запрашивайте 10 000 данных из наименьшего идентификатора на сервер DTS и передайте их DTS для обработки. sql выглядит следующим образом:

select * from table_name where id > curId and id < curId + 10000;

3. Когда идентификатор больше или равен maxId, существующая задача переноса данных завершается.

Конечно, мы можем не использовать Alibaba Cloud в фактическом процессе миграции, или в нашем третьем сценарии нам нужно сделать много преобразований между полями базы данных, DTS не поддерживает его, тогда мы можем имитировать подход DTS, переносим данные с помощью чтение данных в пакетах в пакетах.Здесь следует отметить, что когда мы переносим данные в пакетах, нам необходимо контролировать размер и частоту сегментов, чтобы не повлиять на нормальную работу нашего онлайн.

Инкрементная миграция данных

Схема миграции стоковых данных относительно ограничена, но метод инкрементной миграции данных — это сто цветущих цветов, Вообще говоря, у нас есть следующие методы:

DTS: DTS от Alibaba Cloud — это универсальная услуга, которая обеспечивает не только миграцию стандартных данных, но и добавочную миграцию данных, но за нее необходимо взимать плату в соответствии с суммой.
Двойное написание сервисов: это больше подходит для миграции системы без переключения, то есть меняется только хранилище, но система остается той же, например, подтаблица подбазы данных, синхронизация данных redis и т. д. Это метод относительно прост для записи синхронно в коде напрямую Данные, которые необходимо перенести, импортируются, но, поскольку это не одна и та же база данных, транзакция не может быть гарантирована, что может привести к потере данных при переносе данных.Этот процесс будет решается последующей проверкой данных.
Асинхронная запись MQ: это может применяться ко всем сценариям.При изменении данных отправляется сообщение MQ, и потребитель получает сообщение, а затем обновляет данные. Это немного похоже на вышеупомянутую двойную запись, но он превращает работу базы данных в MQ асинхронную, и вероятность проблем будет намного меньше
Прослушивание бинлога: мы можем использовать канал, как упоминалось ранее, или какой-либо другой открытый источник, такой как шина данных, для мониторинга бинлога.Способ прослушивания бинлога такой же, как и в приведенном выше методе сообщения MQ, но мы опускаем шаг отправки сообщений. Объем разработки этого метода в основном наименьший.

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

Проверка достоверности данных

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

Вообще говоря, когда мы переносим данные, будет этап проверки данных, но разные команды могут выбирать разные схемы проверки данных:

Когда мы были в Мейтуане раньше, мы делали двойное чтение, то есть все наши чтения читались с нового, но возвращенный был все еще старым.На данный момент нам нужно проверить эту часть В случае возникновения проблемы может быть выдан сигнал тревоги для ее устранения вручную или автоматически. Таким образом, наши часто используемые данные могут быть быстро восстановлены, и, конечно, время от времени будет выполняться полная проверка данных, но время восстановления данных после такой проверки относительно откладывается.
Теперь, после Yuanfudao, мы не используем предыдущий метод, потому что, хотя проверка двойного чтения может быстро выяснить, неверны ли данные, у нас нет такой высокой проверки в реальном времени и двойного чтения для этой части данных. , Объем разработки кода все еще относительно велик, но он не может быть гарантирован полномасштабной проверкой время от времени, что приведет к тому, что время проверки наших данных будет очень продолжительным. Мы приняли компромиссный метод.В сверке мы позаимствовали идею T+1.Каждое утро мы получали обновленные вчера данные в старой базе данных, а затем поочередно сравнивали их с данными в нашей новой базе данных.Если Если данные отличаются или отсутствуют, мы можем исправить это прямо сейчас.

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

Как обеспечить правильность задачи проверки данных?Задача проверки заключается в исправлении других данных, но если есть проблема с самой собой, то она теряет смысл проверки.Пока что она может полагаться только на код проверки. обеспечить правильность проверочного задания.
При проверке задания нужно обратить внимание на печать лога.Иногда проблема может заключаться в том,что проблема со всеми данными напрямую.Тогда задание верификации может распечатать большое количество логов ошибок,а потом тревога, что может повесить систему, или Саид повлияет на чужие сервисы. Если вы хотите сделать это проще, вы можете превратить некоторые аварийные сигналы, не обработанные вручную, в предупреждения.Если вы хотите сделать это сложнее, вы можете инкапсулировать инструмент, и печать определенной ошибки превышает определенное количество за определенный период времени. время, после чего печать больше не требуется.
Будьте осторожны, чтобы не повлиять на службу, работающую в сети для задачи проверки.Обычно задача проверки записывает много операторов пакетного запроса, и происходит пакетное сканирование.Если код написан неправильно, база данных легко зависнет.

сократить поток

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

Итак, нам нужно выполнить затем градации серого, то есть вырезать поток. Размерность отсечки для разных сервисов будет разная.Для отсечки по измерению пользователя мы обычно отрезаем поток по модулю userId.Для бизнеса арендатора или мерчанта нам нужно взять по модулю по удостоверению личности арендатора способ сократить поток. Для этого сокращения потока необходимо сформулировать план сокращения потока, в какой период времени, сколько трафика будет выпущено, и при сокращении потока вы должны выбрать, когда поток относительно мал, чтобы сократить поток, и для каждого сокращения потока необходимо делать подробные наблюдения. из логов Если есть проблема, устраните ее как можно скорее.Процесс высвобождения трафика это процесс от медленного к быстрому.Например в начале постоянно накладывается сумма 1%.В последующем время, мы напрямую используем количество 10% и 20%, чтобы идти быстро. Потому что, если есть проблема, она часто обнаруживается при небольшом трафике.Если нет проблем с небольшим трафиком, объем может быть быстро увеличен в последующем.

Обратите внимание на идентификатор первичного ключа

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

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

Конечно, у нас также есть ситуация, когда нам нужно мигрировать систему.Идентификатор первичного ключа предыдущей системы уже существует в новой системе, поэтому наш идентификатор необходимо сопоставить. Если мы уже знаем, какие системы будут перенесены в будущем при переносе системы, мы можем использовать зарезервированный метод.Например, текущие данные системы A составляют от 100 до 100 миллионов, а данные системы B также равны 100. миллионов до 100 миллионов.Теперь нам нужно объединить две системы А и Б в новую систему, тогда мы можем немного прикинуть некоторые Буферы, например, оставить 100 миллионов до 150 миллионов для системы А, чтобы А не необходимо сопоставить, а система B составляет от 150 миллионов до 300 миллионов. Затем, когда мы конвертируем в старый идентификатор системы, нам нужно вычесть 150 миллионов, и, наконец, новый идентификатор нашей новой системы начинает увеличиваться с 300 миллионов. Но что делать, если в системе нет зарезервированного сегмента для планирования? Это можно сделать следующими двумя способами:

Необходимо добавить новую таблицу и сделать запись сопоставления между идентификатором старой системы и идентификатором новой системы.Эта рабочая нагрузка все еще относительно велика, потому что мы обычно переносим десятки или сотни таблиц, а стоимость записей по-прежнему очень высок.
Если идентификатор имеет тип Long, мы можем эффективно использовать фактор, который составляет 64 бита.Мы можем сформулировать правило, согласно которому идентификатор нашей новой системы начинается с относительно большого числа, например, начиная с числа, превышающего Int. , и задает небольшой Int. Эта часть числа может быть оставлена нашей старой системе для переноса идентификаторов. Например, в нашем вышеприведенном объеме данных в 150 миллионов фактически используется только 28 бит. Наш Int равен 32 битам, поэтому есть 4 бита, которые можно использовать. Эти 4 бита могут представлять 16 систем для миграции.Конечно, если для миграции планируется больше систем, начальная точка id новой системы может быть установлена больше. Как показано ниже:

Суммировать

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

Если вы считаете, что эта статья полезна для вас, то ваше внимание и пересылка - самая большая поддержка для меня, O(∩_∩)O: