Comments 15
1. AlwaysOn:…
Доступна только с лицензией Enterprise от 2012 версии и выше.
И сразу в первом пункте неверно: docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2017
AlwaysOn доступен в стандарт в конфигурации из двух узлов и с некоторыми ограничениями. Но доступен.
Always On failover cluster instances
и
Always On availability groups
не одно и тоже (в данном случае в статье описан в п.1 Always On availability groups, а Always On failover cluster instances-это относится к кластеризации)
и
Always On availability groups
не одно и тоже (в данном случае в статье описан в п.1 Always On availability groups, а Always On failover cluster instances-это относится к кластеризации)
На самом деле при тестах в изолированной среде, сам стал жертвой маркетингового хода и сначала тоже думал, что AlwaysOn доступен в Standard на 2 узла. Оказалось-это просто кластер)
По этой ссылке (которую Вы дали): docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/basic-availability-groups-always-on-availability-groups
говорится также об одной БД, что в большинстве случаев недопустимо, т к обычно основная БД взаимодействует с другими БД. И либо тратить деньги на обеспечение ресурсов на каждую БД (лицензии и железо для каждого виртуального сервера), либо купить Enterprise, либо воспользоваться тем, что есть (+свои наработки или наработки сторонних разработчиков, распространяемых в свободной лицензии)
говорится также об одной БД, что в большинстве случаев недопустимо, т к обычно основная БД взаимодействует с другими БД. И либо тратить деньги на обеспечение ресурсов на каждую БД (лицензии и железо для каждого виртуального сервера), либо купить Enterprise, либо воспользоваться тем, что есть (+свои наработки или наработки сторонних разработчиков, распространяемых в свободной лицензии)
Always On failover cluster instancesНет, всё-таки это одно и тоже, но с ограничениями.
и
Always On availability groups
не одно и тоже
говорится также об одной БД, что в большинстве случаев недопустимо, т к обычно основная БД взаимодействует с другими БД.Да, одна БД на одну группу (поэтому эта группа и называется Basic). Но можно сделать несколько Availability Groups (в каждой по одной БД) на одном сервере.
Тут есть небольшой полезный FAQ:
blogs.technet.microsoft.com/msftpietervanhove/2017/03/14/top-5-questions-about-basic-availability-groups
> В любом случае зеркалирование приемлемо, если возможно настроить собственное автоматическое переключение, иначе возможны ложные переключения (например, когда ЦП основного сервера будет загружено более чем на 50%).
Переход активной БД на резервный сервер в случае сбоя основного при наличии следящего сервера происходит полностью автоматически. Никаких «ложных переключений» не бывает, и с нагрузкой ЦП это никак не связано.
Подключение клиента к ведущему (Principal) серверу тоже происходит автоматически; этим занимается сам SQL Server Native Client.
Из недостатков как зеркала, так и кластера является то, что при сбое сервера соединение всегда разрывается, и клиенту необходимо подключаться заново. AlwaysOn не пробовал, но скорее всего там тоже самое.
Переход активной БД на резервный сервер в случае сбоя основного при наличии следящего сервера происходит полностью автоматически. Никаких «ложных переключений» не бывает, и с нагрузкой ЦП это никак не связано.
Подключение клиента к ведущему (Principal) серверу тоже происходит автоматически; этим занимается сам SQL Server Native Client.
Из недостатков как зеркала, так и кластера является то, что при сбое сервера соединение всегда разрывается, и клиенту необходимо подключаться заново. AlwaysOn не пробовал, но скорее всего там тоже самое.
AlwaysOn работает поверх failover cluster'а. В чём отличие:
«Классический» кластер обеспечивает высокую доступность группы ресурсов, в которую входят сервисы SQL Server и общее для узлов хранилище с файлами БД. При отказе основного узла на резервном запускаются сервисы SQL Server, которые обрабатывают файлы БД так же, как при каждом старте (rollforward/rollback) по журналу с диска. Это занимает время.
«AlwaysOn» кластер обеспечивает высокую доступность listener'а, к которому подключаются клиенты. SQL Server запущен на всех узлах, поддерживающих Availability Group. При отказе основного узла переключение на резервный происходит практически со скоростью переноса IP-адреса. Приведение БД в консистентное состояние проходит быстро по данным журнала в памяти.
Активные (на момент сбоя) транзакции теряются в обоих случаях.
Но есть подозрение, что сессии, открытые для чтения (ApplicationIntent=ReadOnly), и работавшие с резервным узлом, могут спокойно продолжать себе работать
«Классический» кластер обеспечивает высокую доступность группы ресурсов, в которую входят сервисы SQL Server и общее для узлов хранилище с файлами БД. При отказе основного узла на резервном запускаются сервисы SQL Server, которые обрабатывают файлы БД так же, как при каждом старте (rollforward/rollback) по журналу с диска. Это занимает время.
«AlwaysOn» кластер обеспечивает высокую доступность listener'а, к которому подключаются клиенты. SQL Server запущен на всех узлах, поддерживающих Availability Group. При отказе основного узла переключение на резервный происходит практически со скоростью переноса IP-адреса. Приведение БД в консистентное состояние проходит быстро по данным журнала в памяти.
Активные (на момент сбоя) транзакции теряются в обоих случаях.
Но есть подозрение, что сессии, открытые для чтения (ApplicationIntent=ReadOnly), и работавшие с резервным узлом, могут спокойно продолжать себе работать
По первому абзацу-во время тестов наблюдались ложные переключения.
Ещё из недостатков-это невозможность усечь журналы транзакций в случае отказа, в следствии чего журналы очень быстро разрастаются для зеркалирования и AlwaysOn
А как вы все это мониторите? Предположим, что все упало в момент, когда лог транзакций только начал копироваться, или только начал восстанавливаться. На какой момент времени вы восстанавливаетесь и как оцениваете размер изменений?
Как и когда вы управляете размером лога и по каким правилам?
Как вы контролируете копирование, вдруг сеть ляжет в процессе?
Как и когда вы управляете размером лога и по каким правилам?
Как вы контролируете копирование, вдруг сеть ляжет в процессе?
Стандартными средствами (ссылки приведены)
Для усечения журналов используется процесс резервного копирования журналов БД, который встроен в зеркалирование, AlwaysOn и доставку журналов.
В последнем при настройке каждые 5 мин делать резервную копию, каждые 5 мин копировать с боевого на резерв и каждые 5 мин восстанавливать на резерве, то потеря в среднем составит 15 мин в случае полного отказа дисков, на котором располагаются общедоступные резервные копии, а так-5 мин. Максимальное время потери-в два раза больше от среднего.
Размером через стандартные счётчики, которые можно вывести в Zabbix например.
К слову при падении основного при зеркалировании и AlwaysOn журнал вырастали более чем 40 гб.
При потере сети также будет видно и оповещалка о задержке свыше установленного, напр 30 мин (также все в ссылках стандартными средствами)
Для усечения журналов используется процесс резервного копирования журналов БД, который встроен в зеркалирование, AlwaysOn и доставку журналов.
В последнем при настройке каждые 5 мин делать резервную копию, каждые 5 мин копировать с боевого на резерв и каждые 5 мин восстанавливать на резерве, то потеря в среднем составит 15 мин в случае полного отказа дисков, на котором располагаются общедоступные резервные копии, а так-5 мин. Максимальное время потери-в два раза больше от среднего.
Размером через стандартные счётчики, которые можно вывести в Zabbix например.
К слову при падении основного при зеркалировании и AlwaysOn журнал вырастали более чем 40 гб.
При потере сети также будет видно и оповещалка о задержке свыше установленного, напр 30 мин (также все в ссылках стандартными средствами)
Изучал доставку журналов и не понял, чем это принципиально отличается от того, чтобы написать свои скрипты. На мой взгляд, получается более прозрачная и гибкая система.
Упрощенно:
На первом сервере — каждые 5 минут локально делается копия журнала, потом копируется на второй сервер (если сбой сети — скопируется когда сеть появится).
А на втором — каждые N минут эти копии восстанавливаются. База в режиме «только для чтения». Отдельное задание проверяет, что всё вовремя копируется.
Почему-то в интернетах такие скрипты не нашел (или плохо искал), хотя вещь очень удобная.
Упрощенно:
На первом сервере — каждые 5 минут локально делается копия журнала, потом копируется на второй сервер (если сбой сети — скопируется когда сеть появится).
А на втором — каждые N минут эти копии восстанавливаются. База в режиме «только для чтения». Отдельное задание проверяет, что всё вовремя копируется.
Почему-то в интернетах такие скрипты не нашел (или плохо искал), хотя вещь очень удобная.
Да, если собственная разработка и она оттестирована с учетом каждого выхода новой версии MS SQL Server, то это тоже отличное решение.
Так и напишите статью об этом-поделитесь с сообществом)
Так и напишите статью об этом-поделитесь с сообществом)
Конечно, скрипты сделаны «под себя», и вряд ли заслуживают отдельной статьи (ну только чтобы получить порцию критики :) ), но функцию свою выполняют.
Но это настолько очевидное решение, что я был удивлен, когда не нашел готовых вариантов. Вот и пришлось сделать, хотя я не специалист по SQL.
Например, из «костылей» пришлось использовать xp_dirtree и тот самый xp_cmdshell (для copy, ren и move) — не уверен, что это идеальный вариант.
А так: банальный бэкап во временный файл, переименование, копирование по сети, на втором сервере — RESTORE LOG WITH STANDBY с последующим перемещением в папку отработанных.
Мне и самому интересно увидеть такие скрипты от действительно разбирающихся в SQL.
Но это настолько очевидное решение, что я был удивлен, когда не нашел готовых вариантов. Вот и пришлось сделать, хотя я не специалист по SQL.
Например, из «костылей» пришлось использовать xp_dirtree и тот самый xp_cmdshell (для copy, ren и move) — не уверен, что это идеальный вариант.
А так: банальный бэкап во временный файл, переименование, копирование по сети, на втором сервере — RESTORE LOG WITH STANDBY с последующим перемещением в папку отработанных.
Мне и самому интересно увидеть такие скрипты от действительно разбирающихся в SQL.
Sign up to leave a comment.
Реализация отказа в MS SQL Server 2017 Standard