Назад | Перейти на главную страницу

Репликация SQL Server 2008 - возможность потери

Существует ли какой-либо тип репликации через глобальную сеть (WAN), который может гарантировать отсутствие потери данных в случае аварии? Всегда ли мы теряем несколько секунд или минут до момента?
Если да, то какие способы уйти? Мы обсуждаем использование облачного хранилища или финансового приложения для регистрации одной или двух наших ключевых транзакций на внешнем сервере.

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

Обратите внимание, это определенно повлияет на производительность. И, вероятно, большое влияние. Каждый раз, когда вы делаете обновление в базе данных, оно будет фиксироваться локально, затем отправлено на удаленный (зеркальный) сервер, обработано и зафиксировано там, затем удаленный возвратит уведомление о завершении транзакции, и только Затем основной сервер БД вернет клиенту сообщение о завершении транзакции. Этот дополнительный круговой обход и обработка вызовут некоторый уровень увеличения задержки.

Для получения дополнительной информации начните с этих статей MSDN:

Примечание: я не администратор базы данных SQL Server. По большей части мой опыт связан с PostgreSQL и Oracle. Может быть лучший или альтернативный способ сделать это. Если да, то, надеюсь, администратор базы данных SQL Server предоставит его или исправит все мои ошибки.

Я бы порекомендовал вам развернуть на месте зеркалирование базы данных или кластеризацию, а затем репликацию журнала транзакций по каналу WAN.

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

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

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

Если вам нужна дополнительная помощь, я более чем рад помочь или порекомендовать. удачи!