Репликация SQL Server 2005 на многие подчиненные серверы - аппаратная репликация или изменение стратегии

Question

У нас есть база данных 500 гб, которая выполняет около 10 000 операций записи в минуту.

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

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

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

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

В идеале решение будет охватывать нас до 1,5 тб база данных со 100 000 записей в минуту

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

Answer 1

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

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

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

Answer 2

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

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

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

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

В случае, если это помогает, я подробно излагаю большинство этих вопросов в своей книге: Ultra-Fast ASP.NET.

Answer 3

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

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

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