Миграция реляционной базы данных в озеро данных S3 через AWS DMS, Часть I

Сервис миграции баз данных AWS Database Migration Service – это облачный сервис, который эффективно и безопасно мигрирует реляционные базы данных, базы данных NoSQL, хранилища данных и все другие типы хранилищ данных в облако AWS или между облаком и локальными настройками. DMS поддерживает несколько типов исходных и целевых баз данных, таких как Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift и S3 и т. д.

Наблюдения во время миграции данных

Мы работали над проектированием и созданием озера данных AWS S3 и хранилища данных в AWS Redshift с данными из источников на локальной машине для Oracle, MS SQL Server, MySQL, Postgres SQL и MongoDB для реляционных баз данных. Мы использовали AWS DMS для начальной полной загрузки и ежедневной инкрементной передачи данных из этих источников в AWS S3.

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

1. Дата изменения не заполнена правильно на исходном сервере

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

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

Приведенный ниже пример кода добавляет новый столбец DMS_CHANGE_SEQ в целевую таблицу, который имеет уникальное инкрементирующее число из источника. Это уникальное число из 35 цифр, в котором первые 16 цифр представляют временную метку, а следующие 19 цифр – номер записи, инкрементируемый базой данных. 

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. Включение дополнительного журналирования для Oracle в качестве источника

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

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

Дополнительное журналирование всех столбцов увеличит размер redo-журналов, так как все столбцы таблицы регистрируются в журналах. Необходимо настроить redo- и архивные журналы соответственно, чтобы учитывать в них дополнительную информацию.

3. Пропускная способность сети между исходной и целевой базами данных

Начальная полная загрузка из источников на местности для Oracle, MS SQL Server и т. д., прошла успешно, и захват измененных данных тоже, в большинстве случаев.

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

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

• CDCLatencySource – разрыв, в секундах, между последним событием, зафиксированным на конечной точке источника, и текущим меткой времени системы экземпляра AWS DMS.
• CDCIncomingchanges – общее количество событий изменения в определенный момент времени, ожидающих применения к цели. Это увеличивается от нуля до тысяч во время активностей по согласованию ранним утром.
• Источник задержки CDCLatencySource – разрыв, в секундах, между последним событием, зафиксированным с конечной точки и текущим меткой времени системы экземпляра AWS DMS. Это значение увеличивается от нуля до нескольких тысяч до 10-12 тысяч секунд во время ежедневных реконциляционных операций после полуночи. Это значение составляло до 40 тысяч во время месячных операций.

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

Метрики AWS DMS NetworkReceiveThroughput помогают понять входящий трафик на экземпляре репликации DMS для базы данных клиента и трафика DMS. Эти метрики помогают понять проблемы, связанные с сетью, если они есть, между исходной базой данных и экземпляром репликации DMS.

Было обнаружено, что сетевой поток приема был до 30 МБ/с, т.е. 250 Мб/с, из-за VPN-соединения между источником и AWS, которое также использовалось для других приложений.

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

1. Туннель VPN, такой как AWS Site-to-Site VPN или Oracle Cloud Infrastructure (OCI) Site-to-Site VPN (Oracle AWS), может обеспечить пропускную способность до 1,25 Гбит/с. Этого будет достаточно для миграции небольших таблиц или таблиц с меньшим трафиком DML.
2. Для крупных миграций данных с большим количеством транзакций в секунду на таблицах следует рассмотреть AWS Direct Connect. Он предоставляет возможность создать выделенное частное подключение с поддержкой полосы пропускания 1 Гбит/с, 10 Гбит/с и т. д.

Заключение

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