Недавно я сделал несколько крупных миграций, и в течение этого постепенно разработал несколько практических лучших практик для себя.Ничего особенного в этом нет, но некоторые из них могут оказаться полезными:
Общие советы
- Перед началом работы убедитесь, что вы понимаете существующую модель данных итребования к новой версии системы.
- Разработайте новую схему базы данных как можно лучше и постарайтесь не напрягаться, поскольку вам потребуется перенести старый контент.
- Используйте каркас с твердой ORM.Мало того, что будет легче разрабатывать новую версию, но и миграция будет намного проще.
Миграция
Код, связанный с миграцией данных, будетбыть частью вашего проекта в течение некоторого времени, так что это хорошая идея, чтобы выделить его пакет / папку (например, legacy).В этом пакете хранятся ваши сценарии преобразования и другие файлы, относящиеся к устаревшей системе.Через некоторое время вы сможете избавиться от него простым rm -rf legacy.
. Сценарии должны выполнять преобразование небольшими шагами.Лучше зацикливаться на таблице несколько раз и делать шаги небольшими, простыми и отлаживаемыми, чем иметь один большой скрипт, который делает все, хотя и быстрее.
Также рекомендуется запускать каждый из этапов в отдельной транзакции и выполнять фиксацию только после ее успешного завершения, чтобы вам не нужно было повторно запускать всю миграцию заново при сбое одного шага.
Весь процесс миграции, а также отдельные шаги или группы шагов должны быть выполнены с помощью одной команды из командной строки, потому что вы будете запускать ее много раз, пока не достигнете окончательной версии, поэтому чем более автоматизированы вытем лучше
Основной сценарий (т. Е. legacy/bin/full-migration) должен выполнить весь процесс (т.е. извлечь свежую копию устаревшей производственной БД, (повторно) создать новую БД и таблицы в ней, выполнить всю миграцию)и это должен быть точно такой же процесс, который вы в конечном итоге запустите после развертывания новой версии на рабочих серверах (только с другой конфигурацией).Это позволит вам тщательно протестировать его в вашей среде разработки.
Поскольку преобразование может занять много времени, полезно регистрировать каждое действие (должно делать обычное print action + object_id).Часто есть несколько строк, которые имеют некоторые неожиданные различия, которые приводят к сбою вашего скрипта или вызывают ошибку целостности ссылки.В таких случаях хорошо видеть, какой это был объект, чтобы вы могли немедленно перейти в БД, проверить данные, соответствующим образом обновить скрипт и снова выполнить неудачный шаг.
Одна вещь, которая оказалась очень полезной дляЯ должен был определить классы моделей также для устаревших таблиц баз данных, используя ORM.Я делал это пару раз в Django, который поддерживает несколько соединений с базой данных и маршрутизацию для каждой модели, поэтому я смог написать сценарии, которые выглядели примерно так (Python):
from legacy import models as old
from catalog import models as new
# Loop through all products from the legacy DB
for old_product in old.Product.objects.all():
# Create an instance of the new product model class
new_product = new.Product()
# Copy and modify attributes as needed
new_product.name = old_product.product_name.strip()
# ...
# Save it to the new database
new_product.save()
Кроме того, чем большеограничительная новая схема лучше (т. е. NOT NULL, где это возможно, проверка внешнего ключа и т. д.), потому что она поможет вам увидеть, где ваши предположения о старой схеме неверны, а также предотвратит попадание неверных данных в вашу новую систему (InnoDB как бэкэнд для MySQL - хорошая идея).
Другая хорошая практика - сохранять старые первичные ключи в новой базе данных, где это возможно.Если после переноса вы увидите что-то странное в новых данных, вы можете вернуться и найти элемент по его идентификатору в прежней системе.