Многопользовательский сервер отказоустойчивости?

Question

Я не администратор базы данных, так что это может быть глупый вопрос, но я все равно спрошу. Мы обновляем наши серверы SQL с 2000 по 2005 год, и мы, вероятно, будем использовать репликацию базы данных или зеркалирование базы данных. Наш администратор баз данных хотел бы «повредить» резервный сервер, что означает, что он хотел бы увеличить наши возможности и возможности, запустив другие приложения баз данных на резервном сервере, так как «он все равно будет сидеть там» (его слова, а не мои) , Это такая хорошая идея? Сейчас наш основной сервер приложений использует только один экземпляр, содержащий более 50 баз данных. Насколько я понимаю, то, что мы делаем сейчас, и то, что предлагает наш DBA для отказоустойчивого сервера, - плохая идея, потому что все эти базы данных разделяют память, процессоры и рабочие области. Если одно приложение начинает плохо себя вести, могут пострадать другие БД.

Любые мысли?

Answer 1

Это действительно деловой вопрос, на который нужно ответить ??? медленное приложение лучше, чем приложение, если вы не можете позволить себе расходы на дополнительное оборудование?

Резервные и зеркальные db могут использоваться для сообщения. Использование этого параметра в качестве резервной базы данных может работать, если у вас достаточно запаса прочности (т. Е. Обе базы данных будут удобно работать на сервере)

Answer 2

Вы будете зависеть от этих дополнительных приложений? Где они работают в случае сбоя?

Answer 3

Вам действительно нужно понять ваши режимы сбоев.

Если вы рассматриваете его как базовую математику ресурсов, это не часто имеет смысл, если только ресурсы, которые у вас запущены в сценариях сбоя, не могут обрабатывать всю ожидаемую нагрузку. Иногда это так, но не всегда. В этом случае для обработки фактической нагрузки вам может понадобиться еще один сервер (например, RAID), возможно, на ваш ресурс требуется минимум 5 серверов, но у вас есть ферма по 6, тогда вам нужен один резервный сервер навсегда для сервера сбой выше 1). Иногда ферма может разрушаться, но иногда они просто страдают и умирают.

И в случае нормальной работы у вас часто возникает авария, когда законный инцидент вызывает каскад проблем - например, ваша резервная лента занята восстановлением сервера из резервной копии (в тестовую среду, даже - нет реальных «сбоев»), теперь ваш сервер sql или сервер exhcange (или оба) не архивируются, и ваш журнал заполняется.

Answer 4

Зеркальное отображение базы данных не могло бы быть здесь, на мой взгляд, поскольку оно обеспечивает избыточность только на уровне базы данных. Поэтому вам необходимо настроить зеркальное отображение базы данных на 50 баз данных на основе предоставленной вами информации. Скорее всего, если бы одна БД, в которой все проваливалась, вероятно, следовало бы, поскольку ошибки обычно происходят на аппаратном уровне, а не в конкретной базе данных.

Мне кажется, что вы должны использовать технологию кластеризации SQL Server. Вы можете создать кластер Active/Active для поддержки ваших требований.

Что такое активный/активный кластер?

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

Применяя это к вашему сценарию

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

Дальнейшее чтение

An introduction to SQL Server Clustering

I suspect that you will find the following MSDN thread useful reading also

Answer 5

"это просто будет сидеть там в любом случае"

Он будет сидеть там, применяя транзакции ...

Обратите внимание на рекомендацию Джона Сансом. Имейте в виду, что для кластера Active/Active требуется две лицензии сервера sql, а для отказоустойчивого кластера/зеркала требуется только один.

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