У нас есть приложение для платежей (обработка транзакций EFT), которое обрабатывает большие объемы транзакций круглосуточно и без выходных, и в настоящее время изучаем лучший способ репликации БД на наш сайт аварийного восстановления.
Наши текущие и предыдущие стратегии включали использование как DoubleTake, так и Redgate для репликации данных в «теплый» резерв.
DoubleTake - это поддерживаемое решение от поставщика программного обеспечения для платежей, однако их поддержка (DoubleTake) в Южной Африке очень слабая. У нас было несколько проблем, и мы просто не могли их решить, поэтому нам пришлось отказаться от DoubleTake.
Мы использовали Redgate для ручного чтения данных с первичного сайта (через запросы) и записи на сайт аварийного восстановления, но это:
Недавно мы обновили всю систему для работы на SQL 2008 R2 Enterprise, что означает, что нам, вероятно, следует подумать об использовании некоторых встроенных функций репликации.
На сервере есть 2 довольно большие базы данных со смесью таблиц, содержащих очень изменчивые данные транзакций и довольно статические данные конфигурации.
Репликация будет выполняться по каналу WAN на отдельный физический сайт и должна достигать следующих целей.
RPO: Zero loss - это транзакционные данные с финансовыми последствиями, поэтому мы ничего не можем потерять. RTO: стремится к нулю - бизнес зависит от нашей способности обрабатывать транзакции каждую минуту, когда мы не работаем, мы теряем деньги
Я просмотрел несколько других вопросов / ответов, но ни один из них не соответствует нашему случаю:
В настоящее время я считаю, что мы должны использовать зеркалирование, но меня беспокоит, что для RPO: 0 нам нужно будет выполнять отложенные фиксации, и это может повлиять на производительность основной БД, что не является вариантом.
Наш текущий процесс аварийного восстановления заключается в следующем:
Другими словами, база данных аварийного восстановления должна как можно быстрее догнать первичную и быть готовой к обработке в качестве новой первичной. Тогда нам нужно будет изменить это, когда мы будем готовы переключиться обратно.
Есть ли лучший вариант, чем зеркалирование (следует ли нам также делать доставку журналов), и может ли кто-нибудь предложить другие соображения, которые мы должны учитывать?
Вы задаете правильные вопросы и хорошо разбираетесь в проблеме, однако планка установлена довольно высоко. Вы упираетесь в стену в поисках чего-то, что может оказаться неуловимым с технологиями, разработанными пять лет назад. Вы уже протестировали двух поставщиков на местах, и они не справились с этой задачей.
Планируйте будущее. У вас есть то, что есть сейчас. Вы можете попытаться модернизировать существующую или старую технологию, но переход на следующую версию может быть вариантом, заслуживающим изучения.
Я подозреваю, что недостатки, которые вы описываете с зеркалированием 2008, являются причиной того, что Microsoft представила возможность AlwaysOn в SQL Server 2012. Зеркальное отображение 2008 года на самом деле неплохо, если у вас нет соединения с зеркалом с высокой задержкой и не используется режим высокой безопасности. Если у вас большой объем транзакций и вы имеете дело с деньгами, высокая безопасность или высокая производительность - непростое решение.
Мое собственное предсказание состоит в том, что так называемые «облачные» провайдеры на самом деле окажутся естественными для многих сценариев аварийного восстановления. У них есть технологии и опыт, которые большинство компаний не может себе позволить, и они стараются ограничить возможности.
Асинхронное зеркальное отображение базы данных (высокопроизводительный режим)
http://msdn.microsoft.com/en-us/library/ms187110%28v=sql.105%29.aspx
Знакомство с SQL Server AlwaysOn
http://msdn.microsoft.com/en-us/sqlserver/gg490638
Часто задаваемые вопросы по AlwaysOn для SQL Server 2012
http://msdn.microsoft.com/en-us/sqlserver/gg508768.aspx
Вы также можете использовать репликацию на уровне хранилища. Таким образом, вы можете получить репликацию на уровне приложения - вашей базе данных и на уровне хранилища.
Поскольку это приложение критично с низкими значениями RPO и RTO, вы можете поискать синхронное зеркало, чтобы обновления выполнялись при появлении дельты на первичной стороне.
Облако - хороший вариант. Он предлагает отличную гибкость, скорость, модель оплаты по мере использования, экономию на масштабе, глобальный охват и т. Д., Но поскольку это требование, связанное с платежами и банковскими операциями, вы должны выбрать частное облако для лучшей безопасности. С другой стороны, частное облако значительно увеличит ваши эксплуатационные расходы и общие затраты.
Таким образом, вы можете рассмотреть метод репликации на уровне программного обеспечения и инфраструктуры.