У нас есть два производственных SQL-сервера с SQL Server 2005 с пакетом обновления 4 (SP4) с накопительным обновлением 3. Оба сервера работают на идентичных физических компьютерах. DELL PowerEdge R815 с 4-мя 12-ядерными ЦП и 512 ГБ (да ГБ) оперативной памяти, с 10 ГБ подключенными iSCSI SAN дисками для всех баз данных и журналов SQL. ОС Microsoft Windows Server 2008 R2 Enterprise Edition со всеми обновлениями SP и Windows. Диск ОС представляет собой массив RAID 5 с 3 x 72 ГБ 2,5-дюймовыми дисками SAS 15 КБ. SAN - это Dell EqualLogic 6510 с 48 x 10K SAS 3,5 "дисками, настроенный в RAID 50, разделенный на различные логические модули для двух серверов SQL, а также общий с машиной Exchange и несколькими серверами VMWare.
У нас более 20 баз данных, 11 из которых имеют высокую доступность с использованием следящего сервера. Следящий сервер - это машина с более низким уровнем мощности, на которой запущен экземпляр SQL Server, который используется только для предоставления следственных услуг. Самая большая зеркальная база данных составляет 450 ГБ и генерирует около 100-300 iops. Монитор зеркального отображения базы данных сообщает о текущей скорости отправки от 100 до 10 МБ в секунду, а также накладные расходы на зеркальное принятие (обычно) 0 миллисекунд. У зеркального сервера нет проблем, чтобы не отставать от принципала.
Мы постоянно испытываем отказоустойчивые зеркалирования. Иногда происходит сбой одной базы данных, в других случаях происходит сбой одновременно почти всех баз данных. Например, вчера вечером у нас было аварийное переключение 10 из 11 баз данных, оставшаяся база данных оставалась доступной до тех пор, пока я не перевел ее вручную.
Я выполнил несколько шагов по устранению неполадок, чтобы попытаться определить проблему, но до сих пор не смог решить проблему:
1) Машина поставлялась с 4-портовым гигабитным сетевым адаптером Broadcom BCM5709C NetXtreme II, который мы изначально использовали в качестве основного сетевого подключения. С тех пор мы установили двухпортовый серверный адаптер Intel (R) PRO / 1000 PT на обе машины, чтобы устранить проблему с сетевой картой.
2) Все базы данных имеют автоматическое полное резервное копирование ночью, а также резервное копирование журнала для баз данных, участвующих в зеркалировании. Использование файла журнала отслеживается и редко используется более 15%. Файл журнала для основной базы данных составляет 125 ГБ, состоящий из 159 виртуальных файлов журнала, размер которых варьируется от 511 МБ до 1 ГБ. TempDB находится на своем собственном LUN и состоит из 24 x 2 ГБ файлов.
3) Журнал SQL Server на свидетеле не показывает никаких ошибок, кроме: Для подключения зеркального отображения к «TCP: //SQL02.DOMAIN.INET: 5022» истекло время ожидания для базы данных «Данные» через 30 секунд без ответа. Проверьте сервис и сетевые соединения.
Журнал SQL Server на первичном и вторичном серверах показывает сообщения, относящиеся к зеркалированию:
Соединение зеркального отображения с «TCP: //SQL01.DOMAIN.INET: 5022» истекло время ожидания для базы данных «Данные» через 30 секунд без ответа. Проверьте сервис и сетевые соединения.
Зеркальная база данных «Данные» меняет роли с «ПРИНЦИПАЛА» на «ЗЕРКАЛО» из-за синхронизации ролей. (Синхронизация здесь ошибочно написана специально, поскольку именно так отображается фактическое сообщение.)
Зеркальная база данных «Данные» меняет роли с «ОСНОВНОЙ» на «ЗЕРКАЛО» из-за аварийного переключения.
Зеркальная база данных «Данные» меняет роли с «ЗЕРКАЛО» на «ПРИНЦИП» из-за отказа от партнера.
Службы SQL Server продолжают работать, и сетевые подключения, кажется, остаются в рабочем состоянии. У нас постоянно есть от 500 до 2500 сеансов, подключенных к каждому серверу (в основном, роботизированные приложения, которые подключаются к очередям сервисных брокеров в одной базе данных).
4) TCP Chimney, RSS и т. Д. Отключены с использованием синтаксиса NET SH.
5) Я запустил анализатор соответствия рекомендациям SQL Server 2005 для обеих машин и не нашел ничего, кроме очень редкой ошибки 833 журнала событий приложений, ни одна из которых не совпадает с событиями аварийного переключения:
SQL Server обнаружил 1 вхождение запросов ввода-вывода, выполнение которых занимало более 15 секунд в файле [F: \ Data.MDF] в базе данных [Data] (9). Дескриптор файла ОС - 0x00000000000010A0. Смещение последнего длинного ввода-вывода: 0x000007d4b10000).
6) Иногда мы видим «Клиенту не удалось повторно использовать сеанс с SPID XXX, который был сброшен для пула соединений. Эта ошибка могла быть вызвана более ранней ошибкой операции. Проверьте журналы ошибок на наличие сбоев операций непосредственно перед этим сообщением об ошибке «. генерируется обоими серверами. Похоже, что нет более ранних сообщений, указывающих на какую-либо проблему.
7) Иногда почта базы данных записывает ошибку в журнал событий приложения:
Тип исключения: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Сообщение: произошла ошибка соединения. Причина: истекло время ожидания. Время ожидания истекло до завершения операции или сервер не отвечает. Параметры подключения: Имя сервера: MGSQL02, Имя базы данных: msdb Данные: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common. SqlConnectionInfo) HelpLink: NULL Источник: DatabaseMailEngine
Информация о StackTrace по адресу Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) в Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.vern String, dameNeringing ) в Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifeMinimumSec, LogLevel loggingLevel)
Я полагаю, что Тайм-ауты вызывают аварийное переключение; что может вызвать эти тайм-ауты? Очевидно, что в случае реальной проблемы в сети, например, неисправного кабеля или неисправного коммутатора, это может привести к потере пакета и, следовательно, к истечению времени ожидания, однако, что еще может вызвать тайм-аут? Блокировка? Если MSDB или какая-либо другая системная база данных имели тайм-аут ввода-вывода, может ли это вызвать аварийное переключение при зеркалировании?
Спасибо за любой совет!
MSDN может сказать следующее о самом механизме тайм-аута :
Механизм тайм-аута зеркального отображения
Поскольку мягкие ошибки не могут быть обнаружены непосредственно экземпляром сервера, мягкая ошибка может потенциально заставить экземпляр сервера ждать бесконечно. Чтобы предотвратить это, в зеркалировании базы данных реализован собственный механизм тайм-аута, основанный на том, что каждый экземпляр сервера в сеансе зеркального отображения отправляет пинг по каждому открытому соединению через фиксированный интервал.
Чтобы сохранить соединение открытым, экземпляр сервера должен получить пинг по этому соединению в течение определенного периода времени, а также время, необходимое для отправки еще одного пинга. Получение ping в течение периода ожидания означает, что соединение все еще открыто и что экземпляры сервера обмениваются данными через него. Получив эхо-запрос, экземпляр сервера сбрасывает свой счетчик времени ожидания для этого соединения.
Если в течение периода ожидания для соединения не получен пинг, экземпляр сервера считает, что для соединения истекло время ожидания. Экземпляр сервера закрывает соединение с тайм-аутом и обрабатывает событие тайм-аута в соответствии с состоянием и режимом работы сеанса.
netsh interface tcp show global шоу:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disablednetsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510SELECT name, value_in_use FROM sys.configurations
Специальные распределенные запросы 0
маска сродства ввода / вывода 0
маска сродства 0
Маска ввода / вывода affinity64 0
маска сродства64 0
Агент XPs 1
разрешить обновления 0
трепет включен 0
порог заблокированного процесса 5
c2 режим аудита 0
CLR включен 1
соответствие общим критериям включено 0
порог стоимости для параллелизма 4
кроссовое владение цепочкой владения 0
Порог курсора -1
База данных Почта XPs 1
полнотекстовый язык по умолчанию 1033
язык по умолчанию 0
трассировка по умолчанию включена 1
запретить результаты триггеров 0
коэффициент заполнения (%) 0
полоса пропускания в футах (макс.) 100
пропускная способность обхода в футах (мин) 0
ft полоса уведомлений (макс.) 100
ft полоса уведомлений (мин) 0
Индекс создания памяти (КБ) 0
xact разрешение 0 под вопросом
легкий пул 0
замки 0
максимальная степень параллелизма 6
максимальный диапазон полнотекстового сканирования 4
максимальная память сервера (МБ) 393216
максимальный размер текста (B) 65536
максимум рабочих потоков 0
удержание СМИ 0
мин памяти на запрос (КБ) 2048
минимальная память сервера (МБ) 52427
вложенные триггеры 1
размер сетевого пакета (B) 1400
Процедуры автоматизации Оле 1
открытые объекты 0
Время ожидания PH 60
предварительный подсчет ранг 0
повышение приоритета 0
ограничение цены регулятора запросов 0
ожидание запроса -1
интервал восстановления (мин) 0
удаленный доступ 1
подключения удаленного администратора 0
тайм-аут удаленного входа 20
удаленный процесс транс 0
время ожидания удаленного запроса 600
Репликация XPs 0
Сканирование для запуска Procs 0
триггер сервера 1
установить размер рабочего набора 0
показать дополнительные параметры 1
SMO и DMO XPs 1
SQL Mail XPs 0
преобразовать шумовые слова 0
двухзначное сокращение года 2049
пользовательские подключения 0
Опции пользователя 4216
Процедуры веб-помощника 0
xp_cmdshell 1
Некоторое время назад я вручную изменил mirroring_connection_timeoutзначение для всех зеркальных баз данных на 30 секунд, чтобы попытаться устранить проблему; это просто увеличило время между событиями отработки отказа. Если для mirroring_connection_timeoutпараметра установлено значение по умолчанию 10 секунд, мы видим гораздо больше отказов.
В комментарии меня попросили убедиться, что IPSec отключен, поэтому я публикую содержимое нескольких netshкоманд, отображающих конфигурацию IPSec операционной системы:
C: \> netsh ipsec dynamic показать все Нет назначенной политики Основные политики недоступны. Политики быстрого режима недоступны. Универсальные фильтры основного режима отсутствуют. Определенные фильтры основного режима недоступны. Универсальные быстродействующие фильтры недоступны. Специальные фильтры быстрого режима не доступны. IPsec MainMode Security Ассоциации не доступны. Ассоциации безопасности IPsec QuickMode недоступны. Параметры конфигурации IPsec ------------------------------ StrongCRLCheck: 1 IPsecexempt: 3 Статистика IPsec ---------------- Активная ассоциация: 0 Разгрузить SA: 0 Ключ в ожидании: 0 Ключевые добавления: 0 Ключевые удаления: 0 ReKeys: 0 Активные Туннели: 0 Bad SPI Pkts: 0 Пкц не расшифрован: 0 Пкц не аутентифицирован: 0 Pkts с обнаружением воспроизведения: 0 Отправлено конфиденциальных байтов: 0 Получено конфиденциальных байтов: 0 Отправлено аутентифицированных байтов: 0 Получено проверенных байтов: 0 Отправлено байт транспорта: 0 Получено транспортных байтов: 0 Отправлено байт в туннелях: 0 Получено байтов в туннелях: 0 Отправлено выгруженных байт: 0 Получено байт: 0 C: \> netsh ipsec static показать все ERR IPsec [05072]: нет политик в хранилище политик
ОБНОВЛЕНИЕ: 2012-12-20
Теперь мы перенесли наши производственные системы на SQL Server 2012. Мы работаем с утра 17 декабря - пока что отказов не было. Однако, пара дней - это то, что мы видели в системах на основе 2005 года.
Стремясь документировать производительность наших новых систем, я sys.dm_os_wait_statsвнимательно изучал их; и заметил DBMIRROR_DBM_EVENT, что это недокументированный тип ожидания. У Грэма Кента в Microsoft есть интересная статья, посвященная устранению неполадок, связанных с непредвиденными отказами, и типу ожидания. Я повторю его выводы здесь:
Заказчик столкнулся с огромной цепочкой блокировок, построенной на базе данных OLTP большого объема, где все блокировщики заголовков ожидали DBMIRROR_DBM_EVENT. Вот последовательность событий, через которые я прошел:
Просмотрите саму цепочку блокировок - помогите, поскольку все, что мы можем видеть, это то, что мы ожидаем DBMIRROR_DBM_EVENT
Просмотрите источник недокументированного типа ожидания. Очевидно, что вы не можете сделать это вне MS, но я могу сказать, что во время написания этот тип ожидания представляет собой ожидание, используемое, когда принципал ожидает зеркала для усиления LSN, то есть транзакция, частью которой он является, не может зафиксировать. , Это сразу определенно указывает на проблему, заключающуюся в том, что принципал не может совершать транзакции, поскольку он ожидает в зеркале. Теперь нам нужно выяснить, почему зеркало не совершает транзакции или почему принципал не знает, так ли это.
Просмотрите системные таблицы msdb
(a) Посмотрите на таблицу [backupset], чтобы увидеть, значительно ли больше размер журналов, созданных во время проблемы, чем обычно. Если они были исключительно большими, возможно, зеркало было заполнено транзакциями и могло просто не поспевать за объемом. Вот почему в онлайновых книгах вам иногда говорят отключить зеркалирование, если вам нужно выполнить исключительно большую занесенную в журнал операцию, такую как перестроение индекса. (ссылка на причину находится по адресу http://technet.microsoft.com/en-us/library/cc917681.aspx ). Здесь я использовал следующий TSQL
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(б) во-вторых, я посмотрел на данные в таблицах [dbm_monitor_data]. Ключевым моментом здесь является определение таймфрейма, в котором у нас возникла проблема, а затем выяснение, были ли у нас значительные изменения в одном из следующих действий:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateВсе эти индикаторы аналогичны части (а) в том смысле, что они могут показывать компонент или часть архитектуры, которая не отвечает. Например, если send_queue внезапно начинает расти, но очередь re_do не увеличивается, это может означать, что принципал не может отправлять записи журнала в зеркало, поэтому вы, возможно, захотите посмотреть на подключение или очереди сервисного брокера. иметь дело с фактическими передачами.
В этом конкретном сценарии мы отметили, что все счетчики, по-видимому, имели странные значения, в том числе происходило резервное копирование журналов нормальных размеров, но не было изменений состояния, 0 очереди отправки, 0 очереди повторов, плоской скорости отправки и плоской повторить скорость. Это очень странно, поскольку подразумевает, что DBM Monitor не может записывать какие-либо значения из любой точки в течение проблемного периода.
Просмотрите журналы ошибок SQL Server. В этом случае не было никаких ошибок или информационных сообщений вообще, но в других сценариях, таких как этот, очень часто сообщают об ошибках в диапазоне 1400, примеры которых вы можете найти в других местах в моих других блогах о зеркалировании, таких как это ошибка 1413 пример
Просмотрите файлы трассировки по умолчанию - в этом сценарии мне не предоставили трассировки по умолчанию, однако они являются фантастическими источниками информации о проблемах DBM, поскольку они записывают события изменения состояния на всех партнерах. Это задокументировано здесь:
Класс события изменения состояния зеркального отображения базы данных
Это часто дает вам отличную картину сценариев, таких как сбой подключения к сети между одним или всеми партнерами, а затем состояние партнерства после этого.
ВЫВОДЫ:
В этом конкретном сценарии в настоящее время я пропускаю 2 ключевых момента данных, но, кроме этого, я все еще могу сделать разумную гипотезу относительно вышеупомянутой информации. Мы, конечно, можем сказать, что блокировка была вызвана тем фактом, что DBM был включен из-за того, что все блокираторы ожидают типа ожидания DBMIRROR_DBM_EVENT. Поскольку мы знаем, что мы не заполняли зеркало большой записываемой операцией и что это развертывание обычно успешно выполняется в этом режиме, мы можем исключить необычные крупные операции. Это означает, что у нас есть 2 потенциальных кандидата на данном этапе:
Аппаратные проблемы с подключением между некоторыми или всеми партнерами.
Исчерпание ЦП на зеркальном сервере - просто не в состоянии угнаться за повторениями - само исчерпание ЦП может происходить из-за процесса вне SQL Server или вне этого зеркального партнерства.
Проблема с самим кодом зеркального отображения (нам действительно нужны некоторые дампы памяти, чтобы подтвердить это).
Основываясь на своем опыте, я подозреваю, что 1 или 2, но я всегда держу непредвзятое мнение и о 3, сейчас мы пытаемся собрать больше данных, чтобы рассмотреть эту проблему более подробно.