Всем привет.

Развернул в тестовой среде:
vSQLAO01 - primary
vSQLAO02 - secondary
vSQLAO-Listen

Создал группу доступности с слушателем.

Не могу сообразить, как отправлять read чтения на secondary?

https://blogs.msdn.microsoft.com/mattn/2012/04/25/calculating-read_only_routing_url-for-alwayson/
При помощи скрипта из этой статьи я сгенерировал read_only_routing_url
Для vSQLAO01 - tcp://vSQL-ENT1.book.ru:50239
Для vSQLAO02 - tcp://vSQL-ENT2.book.ru:49993


но не понимаю, как эти маршруты конфигурирятся.

Хочу добиться, что-бы чтения шли на вторичную группу.

Научите пожалуйста.

Насколько я понял, слушатель должен сам направлять "запросы с намерением только на чтение" на вторичную реплику. Хочется понять, как этим пользоваться?

Как я понимаю, что-бы слушатель автоматически направлял запросы на чтение на реплику, нужно в параметрах подключения указать ApplicationIntent = ReadOnly, после чего select @@servername должен вернуть имя вторичной реплики, но у меня упорно возвращается имя первичной.

Гавриленко Сергей Алексеевич,

Да, вроде как разобрался. А подскажите, как это может использоваться в работе приложений? В чем в таком случае заключается балансировка? Если есть приложение, которое пишет/читает, то оно в любом случае будет работать с первичной репликой, не рвать же каждый раз соединение, если нужно что-то записать, а потом что-то прочитать?

Владислав Колосов,

Получается, что из плюсов, это только единая точка подключения, те листенер. Далее, на уровне приложения мы можем какие то формы грузить с ключом readonly. Хотя это мы делать и так можем подключаясь просто к разным экземплярам. Но если репликами я мог реплицировать только нужные данные, то тут реплицируется все, даже то, что мне читать никогда не нужно - это минус.

Сразу поясню, что отказоустоичивость меня сейчас не интересует, скорее интересовала балансировка чтений/записей по разным серверам и масштабируемость.

Да, эту особенность я уже заметил, когда панель мониторинга показывает что всё отлично и синхронизировано, а redo_queue_size в это время раздувается.

Именно поэтому, я уточнил, что не рассматриваю этот вопрос со стороны отказоустойчивости.

Спасибо, с линкованием серверов интересное дополнение.

Владислав Колосов,

Интересно было разобраться, как работает маршрутизация запросов на чтение внутри AO, так же нравиться, как работает единая точка входа для группы доступности, выглядит многообещающе со стороны масштабируемости системы.

msLex,

Интересно было бы посмотреть на что-то подобное.