Получение рабочей базы данных для работы локально

Я приближаюсь к тому моменту, когда хочу сказать «давай запустим» систему клиента, над которой я работал последние несколько месяцев, в основном это несколько автономных сервисов, включая общедоступный веб-сайт, интранет-сайт, почасовой экспортер из устаревшего OLTP DB на основе модифицированных флагов/триггеров и т. д. и нескольких других служб, составляющих систему, каждая со своей собственной специализированной базой данных и т. д., взаимодействующих друг с другом посредством сообщений (NServiceBus).

Когда я начинал, я пытался поддерживать локальную репликацию всего, но это оказывалось все более и более трудным, и, по размышлении, вероятно, это был главный вопрос последних нескольких недель. Мне нравится регулярно обновляться, поскольку унаследованная база данных растет и вызывает сотни события ежедневно. Наличие высокой задержки и посредственной пропускной способности (между мной и сайтом клиента, я нахожусь в Юго-Восточной Азии, где пропускная способность в любом случае дерьмовая) также является проблемой для RDP, инструментов SQL, строк удаленного подключения и т. д. Отслеживание ошибок интеграции и понимание сценариев они представляют во время обратной связи/интеграции/контроля качества, также сложно, поскольку мои данные не отражают текущее состояние БД клиента (персонал клиента работал и совершенствовал данные в конце) и означает еще один перерыв, кофе и снова длительную синхронизацию . Было бы идеально сделать все это локально, а затем развернуть в конце, но я должен доставлять части постепенно (чтобы получить чек), а некоторые части даже используются (хотя и не критично), поэтому исправление ошибок на используемых патчах требует поворота вокруг быстро, и поскольку это небольшая компания, постепенная обратная связь помогает избавиться от некоторых из наиболее расплывчатых требований на этом пути (будь я проклят).

Я подумал, что было бы хорошо иметь два раза в день синхронизацию между средами (их БД с моей), я в некоторой степени контролирую дизайн всего, кроме устаревшей базы данных SQL-сервера.

Каковы наилучшие варианты для пользователей SO?

Я думал о настройке облегченной виртуальной машины Windows 2003 на моем устройстве разработки. И при этом установите ту же настройку клиентских сайтов (но, очевидно, не распределенную по нескольким серверам). И тогда для синхронизации баз данных я думал о репликации SQL Server? или пакетные скрипты? Или есть какие-нибудь инструменты получше - те, которые обеспечивают быстрое и хорошее сжатие? Я не хочу, чтобы мои изменения возвращались в производство (у меня есть отдельная процедура CI и развертывания), я просто хочу (думаю, что хочу... скажите, если идея лучше), чтобы мои базы данных обновлялись каждую ночь или два раза в день. (возможно, пока я обедаю, если позволяет пропускная способность).

Как все относятся к этому?


person Community    schedule 09.11.2009    source источник


Ответы (1)


Я бы рекомендовал два способа сделать это:

  • Репликация моментальных снимков
  • Резервное копирование журнала транзакций и его ручное (или пакетное) применение

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

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

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

person John    schedule 09.11.2009
comment
Будет ли репликация моментальных снимков автоматически перезаписывать любые локальные изменения, которые я делаю? Скажем, однажды я тестирую редактирование клиента, он делает снимок за ночь, утром все свежо, в идеале, то есть мои изменения теряются (и, конечно, не отправляются обратно в производство). репликация моментальных снимков обрабатывает изменения схемы автоматически? - person ; 09.11.2009
comment
Изменения схемы могут стать настоящей проблемой при репликации. Лучше всего иметь копию первичной базы данных, а затем создать моментальный снимок этой копии для тестирования. Затем вы можете применить «живые» журналы транзакций к копии, повторно сделать снимок копии и внести изменения в снимок. Другие варианты, на которые вы можете обратить внимание, - это сделать копию базы данных в реальной среде, смонтировать ее на живом сервере базы данных, удалить строки и анонимизировать данные, чтобы уменьшить размер базы данных, а затем работать с этим. - person John; 09.11.2009