Односторонняя синхронизация базы данных
=======================================

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

 Исходные данные в бэкэнд-системе сильно нормализованы, с десятками таблиц и ограничениями внешнего ключа. Это хорошо разработанная система СУБД OLTP. Многие из рассматриваемых таблиц содержат миллионы строк. Необходимо регулярно передавать эти данные в другие базы данных. Так часто, как это возможно; задержка может быть допущена. Прежде всего, максимальное время безотказной работы как внутренней, так и удаленной баз данных является обязательным условием.

 Я использую SQL Server и знаком с отслеживанием изменений, изменением строк, триггерами и так далее. Я знаю, что Microsoft активно использует репликацию, SyncFx и SSIS для этих сценариев. Однако между техническими документами поставщиков и обзорами, рекомендующими технологии, и фактической реализацией, развертыванием и обслуживанием решения существует существенная разница. В мире SQL Server репликация часто рассматривается как решение «под ключ», но я пытаюсь найти альтернативные решения. (Есть некоторые опасения, что репликацию сложно администрировать, что затрудняет изменение схемы, и в случае, когда когда-либо потребуется повторная инициализация, для критических систем будут большие простои.)

 Есть много ошибок. Из-за сложных взаимосвязей внешних ключей между большим количеством таблиц определение порядка выполнения захвата или применения обновлений не является тривиальным. Из-за уникальных индексов две строки могут быть заблокированы таким образом, что обновление по одной строке даже не будет работать (необходимо выполнить промежуточные обновления для каждой строки перед окончательным обновлением). Это не обязательно ограничители показа, поскольку уникальные индексы часто можно изменить на обычные, а внешние ключи можно отключить (хотя отключение внешних ключей крайне нежелательно). Часто вы услышите, что «просто» используете отслеживание изменений SQL 2008 и SSIS или SyncFx. Такие ответы на самом деле не соответствуют практическим трудностям. (И, конечно, клиентам действительно трудно понять, как копирование данных может быть настолько сложным, что еще больше осложняет ситуацию!)

 Эта проблема в конечном итоге очень общая: выполнить одностороннюю синхронизацию многих тесно связанных таблиц базы данных с большим количеством строк. Почти каждый, кто связан с базами данных, имеет дело с этим видом проблемы. Белые книги распространены, практический опыт трудно найти. Мы знаем, что это может быть трудной проблемой, но работа должна быть выполнена. Давайте послушаем, что сработало для вас (и чего следует избегать). Расскажите о своем опыте использования продуктов Microsoft или продуктов других поставщиков. Но если вы лично не испытывали в бою решение с большим количеством тесно связанных таблиц и строк, воздержитесь от ответа. Давайте будем практичными, а не теоретическими.

 скрипты не работают в SO, поэтому я должен опубликовать полный ответ)

 Обновление: (переключился на Safari, скрипты снова работают, я могу опубликовать должным образом)

 Там нет серебряной пули. Для простоты использования и развертывания «одним поворотом ключа» ничто не может сравниться с репликацией. Это единственное решение, которое охватываетглубок обнаружение и разрешение конфликтов, имеет поддержку для изменения схемы и поставляется с полным набором инструментов для его настройки и мониторинга. В течение многих лет, до того, как эта «повестка дня» перешла к рассмотрению .Net, эта тема стала детищем MS для синхронизации данных. Репликация имеет две основные проблемы, на мой взгляд:

 Технология, используемая для продвижения изменений, примитивна, медленна и ненадежна. Для инициализации реплик требуются общие файловые ресурсы, и от T-SQL зависит фактическая репликация данных, что приводит к всевозможным проблемам масштабируемости: потоки репликации используют рабочие потоки сервера и тот факт, что они взаимодействуют с произвольными таблицами, а запросы приложений приводят к блокировке. и тупики. Самые большие развертывания, о которых я слышал, - это 400-500 сайтов, которые выполняются сверхчеловеческими MVP и ведущими консультантами. Это останавливает на своем пути многие проекты, которыеНачал на 1500 сайтах (намного больше, чем крупнейшие развернутые проекты репликации). Мне любопытно услышать, если я ошибаюсь, и вы знаете о решении для репликации SQL Server, развернутом с более чем 500 сайтами. Метафора репликации слишком ориентирована на данные. Он не учитывает требования распределенных приложений: необходимость версионных и формализованных контрактов, автономность данных ' [Вотчины](https://msdn.microsoft.com/en-us/magazine/cc164125.aspx) ', слабая связь от доступности и безопасности pov. В результате решение на основе репликации решает насущную необходимость «сделать данные доступными там», но не решает истинную проблему «мое приложение должно общаться с вашим приложением». На другом конце спектра вы найдете решения, которые действительно решают проблему взаимодействия приложений, например, услуги, основанные на обмене сообщениями в очереди. Но либо мучительно медленны, либо пронизаны проблемами, связанными с разделением механизма связи (веб-сервисы и / или msmq) и хранением данных (транзакции DTC между comm и db, нет общей истории высокой доступности, нет общей истории восстановления и т. Д. И т. Д.). Решения, которые [невероятно быстрый и полностью интегрированный с БД существует в стеке MS](https://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx), но никто не знает, как их использовать. Где-то между ними и репликацией вы найдете различные промежуточные решения, такие как OCS / Synch framework и специализированные решения на основе SSIS. Никто не предложит простоту настройки и мониторинга репликации, но они могут масштабироваться и работать лучше.

 Я участвовал в нескольких проектах, которые требовали «синхронизации данных» в очень большом масштабе (+1200 сайтов, +1600 сайтов), и мое решение состояло в том, чтобы превратить эту проблему в проблему «связи между приложениями». Как только мышление меняется на это, и поток данных больше не рассматривается как «запись с ключом X таблицы Y», а вместо этого «сообщение, сообщающее о покупке предмета X покупателем Y», решение становится более простым для понимания и применения. Вы больше не думаете с точки зрения «вставки записей в порядке X-Y-Z, чтобы отношения FK не разрывались», а с точки зрения «процесса покупки, как описано в сообщении XYZ».

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

 Я знаю, что это даже не начинает решать все ваши (очень законные) проблемы, но выписывание всего, что я хочу сказать / rant / rable по этой теме, заполнит тома в мягкой обложке .