Миграция баз данных

Представьте, что вы управляете 600 удаленными серверами в четырех часовых поясах. При этом любой сервер вполне может находиться на каком-нибудь необитаемом острове – собственно, с цифровой точки зрения они там и находятся. Если администратору баз данных потребуется внести изменения вручную, ему придется посетить сотню мест.

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

Другой вариант основан на рассылке сопроводительной документации к выпуску. При выполнении установки директор студии всегда обращался по телефону в службу поддержки за устными инструкциями. Теоретически мы могли разместить сценарии SQL в документах на компакт-диске, чтобы директор мог напечатать или скопировать их. Однако от одной мысли о том, как я буду диктовать: «А теперь наберите mysqladmin – u root – р… », меня бросает в холодный пот.

Вместо этого мы решили автоматизировать обновления базы данных. В Ruby on Rails они называются «миграциями баз данных», но в 2005 году эта технология еще не получила широкого распространения.

Related posts:

  1. Минимум потери данных

Подпишитесь на рассылку по почте:

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>