Репликация SQL Server 2005 на множество подчиненных серверов - аппаратная репликация или изменение стратегии - PullRequest
1 голос
/ 27 ноября 2009

у нас есть база данных 500 ГБ, которая выполняет около 10000 операций записи в минуту.

Эта база данных имеет требования к отчетности в режиме реального времени. Для обслуживания этого у нас есть 10 баз данных отчетов, висящих на главном сервере.

Все 10 баз данных отчетов передаются из основной базы данных 1 с использованием репликации транзакций.

Проблема заключается в том, что сервер и репликация начинают отказывать из-за ошибок PAGEIOLATCH_SH - они, вероятно, вызваны перегрузкой базы данных master. Мы обновляем сервер до четырехъядерной / четырехъядерной машины.

Поскольку эта база данных и потребность в отчетах будут только расти (рост на 20% в месяц), я хотел бы знать, стоит ли нам начинать смотреть на оборудование (или другое стороннее приложение) для управления репликацией (что мы должны использовать ) ИЛИ мы должны изменить репликацию с главной базы данных, реплицирующейся на каждую из баз данных отчетов, на главную репликацию на сервер отчетов 1, сервер отчетов 1, реплицирующий на сервер отчетов 2

В идеале решение будет включать в себя базу данных объемом 1,5 ТБ со скоростью 100 000 операций записи в минуту

Любая помощь с благодарностью

Ответы [ 3 ]

1 голос
/ 27 ноября 2009

В зависимости от того, что вы вставляете, нагрузка в 100 000 операций записи в минуту является довольно легкой для SQL Server. В моей книге я показываю пример, который генерирует 40000 операций записи в секунду (2,4 М / мин) на машине с простым оборудованием. Таким образом, один из подходов может состоять в том, чтобы увидеть, что вы можете сделать, чтобы улучшить производительность записи вашей основной БД, используя такие методы, как пакетное обновление, множественные записи на транзакцию, табличные параметры, оптимизированную конфигурацию диска для вашего журнала и т.д.

Если вы уже сделали столько, сколько можете, то у меня следующий вопрос: какие запросы вы выполняете, для которых требуется 10 серверов отчетов? Кажется необычным даже для довольно больших сайтов. Может также быть куча, которую вы можете сделать для оптимизации на этом фронте, например, выгрузка запросов агрегации в службы Analysis Services или повышение пропускной способности диска. Несмотря на то, что вы можете, масштабирование обычно лучше, чем масштабирование.

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

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

Если это поможет, я подробно расскажу о большинстве этих проблем в своей книге: Сверхбыстрый ASP.NET .

1 голос
/ 27 ноября 2009

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

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

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

0 голосов
/ 28 ноября 2009

Убедитесь, что в файлах журнала транзакций вашего издателя и распространителя не слишком много VLF (виртуальных файлов журнала), как подробно описано здесь (шаг 8):

http://www.sqlskills.com/BLOGS/KIMBERLY/post/8-Steps-to-better-Transaction-Log-throughput.aspx

Если база данных вашего дистрибутива совмещена с базой данных вашего издателя, рассмотрите возможность ее перемещения на собственный выделенный сервер.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...