Вторичный SQL AG в качестве основного 2-й группы

Хотел узнать, что вы думаете о попытке сбалансировать нагрузку на мои 2 узла Always On AG (SQL 2016).

В настоящее время у меня есть x баз данных в одной группе с одним слушателем и двумя узлами (первичный/вторичный).

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

Теоретически это должно сработать, но хотелось бы знать, считает ли кто-нибудь, что это плохая идея?

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


person Marcin Wilczek    schedule 26.04.2018    source источник


Ответы (1)


Я не сторонник такого типа конфигурации. Почему? Предполагается, что оба узла доступны чаще всего (если не все время). Я предполагаю, что ваши узлы имеют правильный размер (в пределах разумных ожиданий использования в будущем) с точки зрения ЦП, ОЗУ и т. д. Что произойдет, если один из этих серверов окажется в длительном перерыве? Может ли ваш единственный оставшийся сервер выполнять рабочую нагрузку обеих групп доступности?

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

person Ben Thul    schedule 26.04.2018
comment
Я согласен с тем, что в случае, когда основной сервер находится в более длительном, чем ожидалось, перерыве, это может быть не лучшим решением, однако основной настроен для обработки всех нагрузок баз данных, как и дополнительный, поэтому в случае, если один из двух узлов должен взять на себя, он сможет справиться с нагрузкой без проблем. Я просто смотрю, смогу ли я больше использовать ресурсы вторичного сервера и немного разгрузить основной. - person Marcin Wilczek; 27.04.2018