Анализ критериев принятия решений для модели выбора инструментов и миграции
Теперь, когда мы изучили варианты методологий миграции и вариантов инструментов, мы можем изучить критерии принятия решений, которые необходимо рассмотреть для выполнения миграции на База данных Azure для PostgreSQL гибкий сервер. Три основных критерия, которые помогают нам сделать выбор: простой, расположение базы данных источника и возможность настройки.
Простой
Простой — это ключевой аспект действий по миграции, а также приемлемый для заинтересованных лиц период, который помогает нам решить, следует ли выполнять действия по миграции в автономном режиме или в режиме онлайн.
Как правило, действия миграции планируются заранее, чтобы обеспечить выполнение соответствующих элементов управления изменениями и связанного управления для действия. Это планирование позволяет диалогу с ключевыми заинтересованными лицами понять, как долго система может находиться в автономном режиме. В этой ситуации рекомендуется знать, сколько времени требуется для различных вариантов, которые можно установить предполагаемое минимальное и максимальное время простоя.
Установка минимального времени простоя, необходимого для выполнения вырезания приложения, является ключом. В конечном счете, на этот раз приходится использовать систему в автономном режиме даже для действия миграции в сети (или минимальное время простоя). Сложность приложения будет диктовать это шкалу времени. Для относительно простого приложения этот процесс может быть случаем остановки службы, обновления файла конфигурации, а затем обратного включения. В более сложных средах этот процесс может занять много времени, если в игре есть несколько серверов и уровней приложений.
Понимание длительности, необходимой для действий в сети или автономной миграции, является следующим важным элементом, связанным с простоем. Если это автономная миграция, время, затраченное на извлечение, передачу и загрузку данных из источника в место назначения, за которым следует проверка и проверка, — это время простоя. Это время простоя затем зажато между временем отключения приложения или рабочей нагрузки и времени, затраченного на включение приложения или рабочей нагрузки.
Если это миграция в сети (минимальное время простоя), время простоя необходимо для синхронизации окончательных изменений из источника в место назначения после отключения приложения. Добавьте в это время простоя, действия проверки и проверки перед последующей настройкой и включением приложения или рабочей нагрузки.
После получения этой информации мы можем ознакомиться с техническими элементами миграции, чтобы помочь определить, какие наши жизнеспособные варианты.
Расположение базы данных-источника
Исходное расположение баз данных, которые необходимо перенести, играет роль из-за ограничений, которые, скорее всего, будут установлены для любой конкретной конфигурации.
Локальные или не являющиеся источниками Azure
Для локальной или не расположенной базы данных Azure ограничение ключа обычно является сетевым подключением между источником и целевым объектом. Три точки, которые следует учитывать здесь, являются пропускной способностью, задержкой и объемом данных. Понимая эти моменты, мы можем принять информированное решение о том, какой тип миграции является жизнеспособным.
Если у нас есть большой объем данных для переноса и пропорционально небольшого объема пропускной способности, то простой дамп и восстановление, вероятно, не будет жизнеспособным. В то время как если у нас есть большой объем данных и большое количество пропускной способности, то это меньше проблем.
Аналогичным образом, если это онлайн-миграция, в которой будет происходить синхронизация данных, задержка является одним из ключевых факторов. Если задержка высока, может оказаться негативное влияние на производительность системы, так как процесс синхронизации занимает слишком много времени.
Одним из важных факторов, которые следует учитывать при миграции с других поставщиков облачных служб, является ли они взимать плату за исходящий трафик данных. Если это так, то возможность свести к минимуму физический объем передаваемых данных может быть вопросом. В таких ситуациях технология сжатия может быть важной для дампов или потоков данных, используемых для синхронизации.
Другие службы на основе Azure
Существуют ситуации, когда вы хотите перенести из других служб Azure в База данных Azure для PostgreSQL гибкий сервер. Эти исходные базы данных могут находиться на виртуальных машинах Azure, контейнерах или, возможно, База данных Azure для PostgreSQL одном сервере. Если это так, то существует другой набор рекомендаций для изучения, но в то же время несколько возможностей для оптимизации в службах Azure для этих сценариев.
Возможности настройки
Последней областью рассмотрения является то, сколько настроек требуется или требуется. Это может принять форму изменения структуры базы данных-источника для поддержки реплика tion данных, а также может означать, насколько легко автоматизировать с помощью скриптов.
Хорошим примером будет автоматизация автономной миграции базы данных с помощью pg_dump и pg_restore, но в то же время, включая сжатие и распаковку файлов дампа.
Принятие решений
Теперь, когда мы прошли процесс сбора всех этих сведений, мы можем работать с заинтересованными лицами, чтобы определить оптимальный вариант для данного сценария. При принятии решения о том, какая методология и технология настроены для использования, важно не только работать с заинтересованными лицами бизнеса, но и техническими заинтересованными лицами. Эта совместная работа помогает избежать ситуации, когда бизнес-диски для минимальной миграции простоя, которую техническая группа не имеет возможности доставить из-за ограничений персонала, ресурсов или технологий.
Ключевой вещью здесь является управление ожиданиями и открытый и честный диалог. Кроме того, важно убедиться, что бизнес берет на себя ответственность за задачи проверки, которые находятся за пределами технической группы, предоставляющей миграцию базы данных. Эта проверка может включать проверку согласованности данных и проверки проверка, а также тестирование взаимодействия с пользователем.