MSDTC и аварийное восстановление идут вместе?
Наше приложение выполняет запись в несколько баз данных Sql Server в рамках распределенной транзакции. Парни из Ops говорят, что это портит их план аварийного восстановления, потому что, хотя транзакции на живых таблицах могут фиксироваться одновременно, доставка журналов по отдельным базам данных происходит в несколько разное время. Таким образом, в ситуации аварийного восстановления будет несколько частичных транзакций.
Есть ли способ для поддержки отдельных, но синхронизированных баз данных в DR? Или мы должны изменить дизайн относительно независимых баз данных (или единой базы данных)?
2 ответа
Я не уверен, каков ваш план аварийного восстановления при операциях, но вы можете восстановить конкретную транзакцию, которая гарантирует, что все базы данных находятся в согласованном состоянии. Для этого вы будете использовать помеченные транзакции.
Одним из ограничений этого подхода является то, что вы можете восстановить только отмеченную транзакцию, а не конкретный момент времени. Я не уверен, портит ли это вашу стратегию или нет.
Из статьи выше, основной подход:
- Создайте полную или дифференциальную резервную копию базы данных каждой из связанных баз данных.
- Отметить блок транзакции во всех базах данных.
- Создайте резервную копию журнала транзакций для всех баз данных.
- Восстановите резервные копии базы данных с помощью NORECOVERY.
- Восстановление журналов с STOPATMARK.
Обратите внимание, что во время двухфазного принятия для транзакции с меткой транзакции другие транзакции будут заблокированы, что может повлиять на производительность.
Использование помеченных транзакций, IMO, является лучшим способом поддержания логической целостности приложения через отдельные физические границы в ваших базах данных.
Другой вариант - использовать зеркальное отображение SQL ( http://technet.microsoft.com/en-gb/library/cc917680.aspx). Короче говоря, это метод обеспечения завершения транзакций в двух базах данных (одна на главном сайте, одна на сайте DR), прежде чем он будет помечен как завершенный. Существуют очевидные последствия для производительности, и вам необходимо определить, является ли это проблемой для вашего приложения.