Советы и извлеченные уроки
В прошлом я работал над большим количеством миграций баз данных.
Не все миграции баз данных одинаковы. Однако я заметил повторяющиеся закономерности. Недавно я участвовал в миграции базы данных, которая длилась около трех месяцев. Этот опыт напомнил мне, что те же самые уроки все еще применимы.
Я буду использовать этот пост в блоге, чтобы записать эти уроки, пока они еще свежи в моей памяти.
Я не предоставляю исчерпывающий список. Некоторые из моих советов могут показаться очевидными опытным разработчикам, которые в своей карьере неоднократно переносили базы данных.
Выбор технологий
Вопросы, которые следует задать, делая этот выбор:
- Какие существующие инструменты вы можете использовать для своего приложения, чтобы мне не пришлось писать с нуля?
- Каковы масштабы миграции?
- Это разовая миграция? Могла ли миграция растянуться еще на несколько месяцев, т. е. миграции с длинным хвостом?
Создайте свой инструмент миграции с нуля. Раньше, до того, как облачные сервисы стали популярными, я запускал сценарий переноса базы данных с удаленного сервера. Я запускал его, надеясь, что не будет длительных простоев и сохраняя целостность данных. Специальные сценарии хорошо работали для одноразовых и небольших миграций. Я бы написал сценарий с нуля, если в наборе инструментов моего приложения нет бесплатных инструментов миграции базы данных.
Встроенные инструменты миграции. Писать инструмент с нуля — не лучший подход, если у вас есть существующие инструменты для повторного использования.
Используйте готовые инструменты, если они доступны. Некоторые платформы с открытым исходным кодом поставляются со своими инструментами миграции. Раньше я использовал инструменты миграции Django и Flask. Эти инструменты миграции хорошо зарекомендовали себя при миграции баз данных малого и среднего масштаба. Инструменты с открытым исходным кодом обычно поставляются с хорошей документацией и активным сообществом.
Вы можете проверить документацию или обсуждения в сообществе, если вы столкнулись с проблемами, с которыми уже сталкивался кто-то другой.
Рабочие процессы. Недавно я использовал рабочие процессы Cadence со своей командой для переноса базы данных. Решение использовать Cadence было простым, потому что наша инженерная организация широко поддерживает его использование. Cadence также имеет расширенные функции, такие как обработка повторных попыток и тайм-аутов, а также многие другие. Функции Cadence упрощают создание надежных рабочих процессов миграции. Рабочие процессы также достаточно гибки, чтобы выполнять необходимые нам миграции между различными базами данных, включая Google Spanner и Firestore.
Вариант сухого хода
Укажите параметр dry-run при запуске сценария миграции. Использование параметра dry-run полезно для отладки логики кода миграции в вашей локальной среде разработки.
Команда будет выглядеть так:
run-migration --dry-run=true
Это позволяет вам просмотреть, что будет делать сценарий миграции, не выполняя фактическую запись в базу данных. например Распечатайте запрос на обновление SQL, который вы ожидаете запустить, а затем пропустите выполнение запроса на обновление SQL, если параметр dry-run имеет значение true.
Простой пример:
logger.Info("running query", query)
if !dryRun {
executeSql(query)
}
Опция ограничения
Предоставьте возможность группировать количество строк, которые вы хотите обработать при переносе.
run-migration --limit=100
Параметр limit полезен для:
- Тестирование. Вы можете выбрать управляемое количество строк для тестирования.
- Пакетная обработка. Вы можете выполнять миграцию небольшими партиями, подтверждать результаты для каждой партии и повторять процесс. Небольшие партии помогают уменьшить площадь поверхности любых потенциальных проблем, которые могут возникнуть.
Регистрация, мониторинг и оповещение
Вы можете сойти с ума от своих журналов при тестировании миграции.
Однако при выполнении миграции в рабочей среде записывайте в журнал только важную информацию. Миграции могут включать тысячи строк. Раздувание панели ведения журналов избыточной информацией затруднит устранение неполадок в случае возникновения проблемы. Пересмотрите свои панели мониторинга, показатели и критерии оповещения.
Вы легко обнаружите потенциальные проблемы, вызванные миграцией, если заранее настроите инструменты мониторинга и оповещения.
Песочница или тестовая среда
Протестируйте миграцию в среде песочницы, которая очень похожа на вашу производственную среду. Независимо от того, сколько времени вы потратите на локальное тестирование, вы, скорее всего, обнаружите проблемы, которые не обнаружили в своей локальной среде. Например, обработка неудачных вызовов API или непредвиденных значений.
Предварительная загрузка запросов или зависимостей
Если ваша организация требует, запросите то, что вам нужно, у вашей команды DevOps или инфраструктуры заранее. например Создание экземпляра базы данных песочницы. Вы не хотите, чтобы вас заблокировали в начале миграции из-за зависимости от других команд.
План тестирования
Подготовьте тестовые примеры, которые помогут вам подтвердить, что миграция не нарушила целостность вашей базы данных и не привела к ошибкам. например Проверьте, загружается ли список, отображаемый в веб-приложении, как ожидалось, или нет повторяющихся записей, которые могут вызвать ошибку API.
Добавьте буфер при оценке ваших задач
Всегда учитывайте закон Мерфи при выполнении миграции базы данных, независимо от масштаба. При оценке баллов за пользовательские истории или задачи, связанные с миграцией, добавьте буфер для непредвиденных проблем и/или наихудшего сценария.
Длинный хвост миграции
Длинный хвост миграции влияет на возможности вашей команды, поэтому вам следует решить их заранее. Установите ожидания с вашей командой и заинтересованными сторонами, если вы ожидаете, что миграция может продлиться дольше, чем квартал. Напишите задачи, необходимые для решения длинного хвоста миграции. Следите за выполнением этих задач во время планирования спринта и следите за тем, чтобы они не провалились.
Разовые миграции
Для одноразовых миграций у вас есть возможность заставить всю команду сосредоточиться на работе над миграцией за пару спринтов. Вовлечение всей вашей команды работает хорошо, если вы можете разбить задачи миграции таким образом, чтобы ваша команда могла работать над ними параллельно.
Предположим, что однократная миграция невозможна. Вы можете разбить миграцию на более мелкие истории и задачи, над которыми пара разработчиков будет работать в каждом спринте в течение всего квартала.
Не нужно быть супер придирчивым в код-ревью
Хотя я все еще поощряю хорошие методы кодирования.
Существует высокая вероятность того, что ваш код миграции будет относительно недолговечным. Если вы повышаете PR, укажите, какие файлы являются временными, которые вы в конечном итоге удалите. Добавьте TODO или создайте дополнительную задачу в невыполненной работе. Если вы просматриваете, используйте свое суждение с сочувствием, зная, какой фрагмент кода недолговечен.
Это баланс между правильными стандартами кодирования и тем, что имеет смысл в вашей ситуации.
Пишите пользовательские истории
То, чем часто пренебрегают, — это важность передачи информации о ценности миграции базы данных через пользовательские истории.
Например, вы получили жалобы пользователей на то, как медленно загружается устаревшее веб-приложение. После обсуждения с вашей командой вы решили выполнить миграцию, при которой вы создаете новый индекс, чтобы ускорить запросы к таблицам.
Вместо того, чтобы писать:
Create a new index X in table Y…
Вы можете написать:
As a user, I want to load my list of documents within n milliseconds…”
Напишите свои пользовательские истории миграции таким образом, чтобы заинтересованные лица, просматривая ваш невыполненный заказ, понимали, почему вы отдаете приоритет такой работе по миграции базы данных.
