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

Лучший подход для достижения высокой доступности и аварийного восстановления?

Мы развертываем SQL-серверы на двух географически удаленных объектах. Пропускная способность между двумя сайтами составляет 10 Мбит / с. Требуется, чтобы оба сайта были доступны для записи и чтения. Оба сайта имеют требование избыточности внутри сайта, и в то же время они синхронизируются друг с другом. Однако эти два сайта не будут писать в одну и ту же строку таблицы. Каков наилучший подход для достижения максимальной доступности и сведения к минимуму возможных потерь данных? Мы думаем об использовании SQL Server 2016 и стараемся избегать использования устаревших технологий, таких как зеркалирование данных.

Я бы согласился с @Sean, однако с каналом 10 Мбит / с, если вы используете синхронную или асинхронную запись на другой сайт, вы можете очень легко затопить канал.

Синхронно записывает все изменения каждого в базу данных в реальном времени, транзакция не завершается, пока не будут выполнены обе записи. Требуется большая пропускная способность, если ваша база данных интенсивно изменяется. Не рекомендуется для прицела DR.

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

Если вы хотите, чтобы оба сайта были доступны для чтения и записи, вам действительно нужна большая пропускная способность, группы доступности SQL Server AlwaysOn - это один читатель / писатель, один читатель, поэтому оба сайта не могут писать одновременно, если ваш кворум не настроен должным образом, вы можете в конечном итоге с разделенным мозгом.

Также вы говорите, что можете путать HA (высокая доступность) и DR (аварийное восстановление). Сначала создайте свой HA, обычно это намного дешевле, если вы не доверяете центру обработки данных, в котором находитесь, переместите его в другой, который лучше, или перейдите в облако.

Основная функция высокой доступности в SQL Server сегодня называется группами доступности AlwaysOn: Обзор групп доступности AlwaysOn (SQL Server)

Я думаю, что вам нужно с геоизбыточным HA / DR: Кластеризация нескольких подсетей SQL Server (SQL Server)

Ссылка: https://social.msdn.microsoft.com/Forums/en-US/34bc95e8-5cce-4586-b82c-d6225e172f93/best-approach-to-achieve-high-availability-and-disaster-recovery?forum=sqldisasterrecovery