Синхронная фиксация группы доступности - вопрос записи / чтения

Question

Мы настроили для нашего клиента доступную группу с синхронным режимом фиксации и двумя кластерами. Один кластер является основным кластером, и он доступен для записи и чтения. Другой кластер является вторичным и доступен только для чтения. Мы используем вторичный кластер для операций только для чтения. Также мы используем этот кластер на портале asp.net для чтения БД и первичный кластер для записи в БД. При тестировании портала и функциональности AG мы обнаружили проблему. Если изменить данные на портале в некоторых таблицах БД и нажать "Сохранить", при обновлении сайта будут отображаться старые данные, пока мы не обновим сайт снова. Первый вопрос: что именно означает режим синхронной фиксации? Могу ли я прочитать данные с вторичного сервера сразу после того, как данные будут зафиксированы на первичном?

Я пишу таблицу и сценарий на базе данных, чтобы проверить функциональность чтения / записи.

Создайте таблицу для тестирования:

CREATE Table temp.tblAuthors
(
   Id int identity primary key,
   Author_name nvarchar(50),
   country nvarchar(50)
)

Первый скрипт для вставки 30000 строк данных в первичный кластер:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
GO

BEGIN TRANSACTION A;

DECLARE @Id INT

SET @Id = 1

WHILE @Id <= 30000
BEGIN
    INSERT INTO TEMP.tblAuthors
    VALUES (
        'Author - ' + CAST(@Id AS NVARCHAR(10)),
        'Country - ' + CAST(@Id AS NVARCHAR(10)) + ' name'
        )

    SET @Id = @Id + 1
END

COMMIT TRANSACTION A;

PRINT CONVERT(VARCHAR, SYSDATETIME(), 121)

Второй скрипт для чтения вторичного кластера каждые 2 миллисекунды в цикле:

DECLARE @i INT = 1;
DECLARE @PrintVarchar NVARCHAR(max)

WHILE (@i <= 60000)
BEGIN
    WAITFOR DELAY '00:00:00.002'

    SELECT Count(*),
        CONVERT(VARCHAR, SYSDATETIME(), 121)
    FROM TEMP.tblAuthors

    PRINT @PrintVarchar

    SET @i = @i + 1;
END

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

Результат:

Commit on primary:     2019-11-26 06:55:58.9978911 
Readable on secondary: 2019-11-26 06:55:59.8104941

Данные на вторичном кластере становятся доступными для чтения примерно через одну секунду после фиксации на первичном кластере. Это объясняет проблему сохранения-обновления на портале. Мы сохраняем данные на основном сервере, и обновление происходит быстрее, чем задержка после фиксации.

Может ли кто-нибудь объяснить это явление? Подходит ли этот случай для портала asp.net или мы должны использовать для портала только первичный кластер?

Извините за мой плохой английский.

С наилучшими пожеланиями,

Alex

Answer 1

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

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