Подумал я грешным делом а не научится ли мне жить на два датацентра, как это делают взрослые компании. Думаю - MS SQL это же классный сервер, столько бабла за него отдаем. Entrerprise редакция обязана уметь master-master репликацию. Начал читать и тут постигло меня разочарование страшное. Выяснилось что умеет MS SQL в области высокой доступности приблизительно ничего. Ну то есть на уровне MySQL. Это был спойлер, а теперь расскажу по порядку.
Первое что предлагает Microsoft - это высокая доступность по высоким ценам, типичное enterprise решение - покупаешь SAN(СХД или хранилка по нашему), подключаешь ее к двум серверам. На этот шаренный диск ставишь MS SQL Server и получаешь решение которое называется Windows Failover Cluster или SQL Server Failover Cluster Instances (FCIs). По сути база и лог транзакций хранится на шаренном диске, только один SQL Server может принимать/обрабатывать транзакции, второй стоит рядом. Эта архитектура не гарантирует ни высокую доступность ни распределенность. Единственное для чего он годится - это установка обновлений. Ставишь обновления на пассивную ноду, переключаешься - смотришь, если все ок - ставишь обновления на вторую ноду.
Следующее что нам предлагает Microsoft - это Availability Groups(AG). У этой штуки есть еще коммерческое название - Always On Availability Groups. Microsoft не была бы Microsoft если бы не придумала для банальной репликации "продающее" название. Да, к сожалению вы не ослышались - весь этот хваленый Always On это банальная master->slave репликация с кучей ограничений. Дело в том что Always On требует наличия Windows Server Failover Clustering(WSFC), который в свою очередь опирается на Active Directory и требует чтобы все сервера входящие в WSFC находились в одном домене. Отсюда вытекает интересное следствие - Availability Group также должна находится в одном домене, соответсвенно использовать Availability Group для репликации между серверами находящимися в разных датацентрах становится практически невозможно (только если вы не хотите растянуть один домен на два датацентра, а вы скорее всего не хотите этого делать). Еще Availability Group не поддерживает больше 8 реплик (даже в Enterprise редакции). Ну и естественно Availability Group не поддерживает master-master репликацию.
Так что же умеет Availability Group ? Умеет перенаправлять read-only траффик на реплику. Причем для того чтобы это работало само приложение должно указать при подключении флаг - ApplicationIntent=ReadOnly. То есть коннекты должны быть разделены на read only и read-write на уровне приложения, а это значит что неподготовленное приложение вы не сможете просто так отмасштабировать на чтение. Потребуется рефакторинг. Отдельно стоит рассказать как происходит разделение траффика на read/write. Если вы подключаетесь к Availability Group Listener то вы подключитесь к primary replica (SQL Server master) и SQL Server отвечает за то чтобы знать топологию AG и если в нем имеется нода в состоянии synchronized настроенная для приема read-only запросов, то SQL Server отправляет клиенту параметры для прямого подключения к read-only серверу. Такой редирект на уровне MS SQL протокола поддерживают далеко не все клиенты.
Еще AG умеет реплицироваться синхронно и асинхронно. Умеет auto failover, но только если:
- Используется синхронный режим репликации
- Реплика на которую мы планируем failover находится в состоянии synchronized
- Windows Server Failover Clustering(WSFC) имеет кворум.
- Autofailover настроен должным образом
В общем у меня не получилось придумать сценария при котором автоматическое переключение могло сработать как надо. WSFC по сути отвечает за синхронизацию на уровне серверов, и если на уровне серверов связи нет(нет кворума) - то автопереключение работать не будет. То есть при физическом отказе сервера сказки не случится. А зачем тогда весь этот цирк с конями если он работает только во время плановых учений ?
При использовании асинхронного режима оно умеет только в ручную переключать master на одну из реплик с частичной потерей данных, причем про частичную потерю данных говорится при каждом упоминании. Чтобы все сразу воодушевились - как здорово просрать данные. Давай немедленно использовать асинхронную репликацию. Причем как при ее использовании данные не просрать не сказано. К примеру тот же MySQL лет 10 как умееет failover без потери данных при асинхронной репликации.
Отдельно стоит рассказать о взаимоотношениях между WSFC и AG. Как я уже сказал AG опирается в своей работе на WSFC. WSFC в свою очередь отвечает за мониторинг состояния SQL Server запущенного на локальной машине и за поддержание связности с другими серверами входящими в WSFC кластер. Мониторинг состояния SQL сервера сделан в стиле Microsoft - через shared memory. Есть процесс RHS.exe который шарит память с SQL Server, они там по очереди timestamp обновляют. Не обновил timestamp - значит умер. Идея здравая, но зачем это через shared memory делать ??
Следующий интересный момент - как происходит failover. Для подключения к Availability Group используется так называемый Availability Group Listener. Listener состоит из Network Name Resource про который я уже писал и порта. Когда происходит failover все коннекты обрубаются, и клиенты начинают переподключаться. Сколько-то retry делается внутри SQL клиента, но также рекомендуется выполнять переподключения в приложении. И в общем после какого-то количества повторов клиенты подключаются к новому серверу.
На этом казалось бы уже длинная сказка про отсутсвие вменяемого HA setup-а должна подойти к концу. Но надо рассказать про еще одного героя - Distributed Availability Group. DAG появился как костыль, позволяющий строить cross-site setup (инсталяции работающие более чем в одном датацентре). DAG позволяет объединить 2 или более AG в единую Availability Group. По сути позволяет реплицировать лог транзакций из primary replica одной AG в primary replica другой AG, а та уже в свою очередь реплицирует его на свои slave-ы. То есть DAG позволяет построить многоранговую сеть репликации и обойти ограничение на 8 slave-ов. Автоматически реплицироваться она не умеет, все это придется делать руками.
В общем как-то так. Никакой master-master репликации там близко нет.
Комментариев нет:
Отправить комментарий