Рабочие моменты Database Mirroring

Рабочие моменты Database Mirroring

Автор: Konstantin Kosinsky

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

1. Некорректный расчет полосы пропускания

Одним из плюсов Database Mirroring заключается в том, что основную и резервную систему связывает только сеть, а значит сервера можно расположить на большом расстоянии друг от друга и тем самым обеспечить защиту от выхода из строя целой площадки. Но если сервера расположены далеко друг от друга, то пропускная способность канала и его задержки могут повлиять на производительность. Особенно, что проявляется с синхронном режиме (асинхронный доступен только в Enterprise Edition), т.к. пока зеркало не подтвердило получение и сохранение транзакции, она не завершается и клиент ждет.

Следовательно, при планировании зеркалирования нужно оценить сколько данных и как часто будут передаваться между системами. Самый простой способ это сделать – это запустить Performance Counter, который будет собирать данные о количестве отсылаемых данных SQLServer: Database Mirroring – Bytes Sent/sec, но для этого уже нужно иметь работающее зеркалирование (например, на стоящий рядом сервер). Если это сделать нельзя, то приблизительные данные можно получить со счетчика SQLServer: Databases – Log Bytes Flushed/sec (который показывает скорость сброса данных в Transaction Log).

Еще одно замечание. В SQL Server 2008 передаваемым на зеркало данные сжимаются, что также позволяет выиграть на полосе пропускания.

2. Частая и неоправданная реиндексация

Реиндексация снижает уровень фрагментации индексов и в результате повышает скорость выполнения операций с ними. Но когда вы делаете реиндексацию выполняется генерация большого объема Transaction Log’а, которые передается на зеркало. И если запустить полную реиндексацию ВСЕ базы данных в 10-ки или 100-ни Гб, а канал между серверами не самый быстрый, то операция может растянуться на часы или даже дни.

По этому нужно реиндексировать только то, что действительно нужно:

  • Не используйте DBCC DBREINDEX, во-первых, этот механизм depricated начиная с SQL Server 2008, а во-вторых реиндексация в таком случае сводиться к простому SELECT …. INSERT… для всей таблицы, что приведет к тому, что будет прочитанна и заново записанна ВСЯ таблица и ВСЕ индексы, и это будет передано на зеркало.

Для реиндексации нужно использовать:

ALTER INDEX PK_Employee_BusinessEntityID ON HumanResources.Employee REBUILD;

а для реогранизации:

ALTER INDEX PK_ProductPhoto_ProductPhotoID ON Production.ProductPhoto REORGANIZE ;

Это позволит делать эффективное и выборочное перестроение

  • Перед операцией определить, что действительно нужно реиндексировать. Т.к. реиндексация и/или реорганизация индекса нужна только если он слишком фрагментирован, то нужно сначала определить уровень фрагментации. Для этого можно воспользоваться системной табличной функцией sys.dm_db_index_physical_stats и значением возвращаемым в столбце avg_fragmentation_in_percent:
SELECT t.name, st.avg_fragmentation_in_percent, st.page_count
FROM sys.dm_db_index_physical_stats (NULL, NULL, NULL, NULL, NULL) st
JOIN sys.objects t on st.object_id = t.object_id
order by st.avg_fragmentation_in_percent desc
Если процент фрагметации:
  • меньше 5%, то делать ничего не нужно;
  • от 5 до 30%, то нужно сделать реогранизацию индекса (перестроить только листовый страницы индекса);
  • если больше 30%, то стоит делать реиндексацию индекса

3. Организация сети, которая приводит к ложным срабатываниям механизма переноса

Обычно схему Database Mirroring рисуют следующим образом:

image

Задача Witness’а следить за ситуацией и если Primary вышел из строя, то сказать Mirror’у, что теперь он активен. Зачем нужен Witness и почему Mirror, не может сам следить за Primary? На самом деле Mirror тоже следит за Primary, а Witness нужен, чтобы при сбое соединения между Primary и Mirror не происходило ложное срабатывание процедуры переключения, после которого у на будут два активных сервера, потерявших синхронизацию.

Как конфигурирую на самом деле:

image

И когда рветься связь между Primary и Switch, то и Witness, и Mirror видят, что Primary не доступен и начивают процедуру активации. Ложную.

Что делать? Не пожалеть средств на установку дополнительных сетевых карт и реализовать топологию с верхней картинки, либо отказаться от Witness’а и делать ручную активацию в случае сбоя.

Запись опубликована в рубрике Mirroring с метками , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Войти с помощью: