Допитливий випадок HADR_SYNC_COMMIT

Ми помічаємо цікаву схему HADR_SYNC_COMMITочікувань у нашому середовищі. У нас є три репліки; одну первинну, одну вторинну синхронізацію та одну вторинну асинхронізацію в центрі обробки даних, і ми просто додали ще три репліки ASYNC в інший центр обробки даних (~ 2400 миль один від одного).

З тих пір ми почали помічати величезне збільшення HADR_SYNC_COMMITочікувань. Переглядаючи активні сеанси, ми бачимо купу COMMIT TRANSACTIONзапитів, що очікують на репліку SYNC

З скріншоту ми чітко бачимо, що HADR_SYNC_COMMIT29 червня спостерігається стрибок у очікуванні, і ми врешті-решт опівдні 1 липня опустили "дві" з трьох реплік асинхрони у віддалений центр обробки даних. Це значно скоротило час очікування разом з ним.

Що ми перевірили поки що - черга на відправлення журналу, чергу повторення, час останнього затвердіння та час останнього введення у віддалені репліки. У нас є безперервні спалахи дрібних транзакцій протягом робочого часу, а тому черги на надсилання досить невеликі в заданий час (від 60 КБ до 1 МБ).
Віддалені репліки майже не синхронізовані, різниця між часом останнього фіксації та останнім затверділим часом для будь-якого окремого lsn на репліках є дуже малою.

Мережева труба становить 10G, і ми змінили розмір буфера передачі з 256 мег до 2 гігів, це було зроблено за припущенням, що мережа скидає пакети і повторно передає їх; будь-який спосіб, який, здавалося, не дуже допомагає.

Отже, мені цікаво, що стосується реплік ASYNCHADR_SYNC_COMMIT ? Чи не повинна репліка SYNC самостійно залежати від цього типу очікування, чого я тут пропускаю?

Спочатку опис події очікування, що стосується вашого питання, це:

Очікуємо на обробку фіксації транзакцій для синхронізованих вторинних баз даних для затвердіння журналу. Це очікування також відображається лічильником ефективності затримки транзакцій. Цей тип очікування очікується для синхронізованих груп доступності та вказує час для надсилання, запису та підтвердження журналу до вторинних баз даних.

https://msdn.microsoft.com/en-us/library/ms179984.aspx

Заглибившись в механіку цього очікування, ви отримаєте блоки журналів, які будуть передані та затверджені, але відновлення не завершено на віддалених серверах. Зважаючи на це, виходячи з того, що ви додали додаткові репліки, очевидно, що ваш HADR_SYNC_COMMIT може збільшитися через збільшення вимог до пропускної здатності. У цьому випадку Аарон Бертран абсолютно коректний у своїх коментарях до цього питання.

Джерело: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

Перегляньте другу частину вашого питання про те, як це очікування може бути пов’язане з уповільненням роботи програми. Це, на мою думку, є причиною причинності. Ви дивитесь, що ваші очікування збільшуються, і нещодавня скарга користувача та робить висновок потенційно неправильно, що вони мають стосунки, коли це взагалі не може бути. Той факт, що ви додали файли tempdb і ваша програма стала більш чуйною до мене, вказує на те, що у вас, можливо, виникли деякі основні проблеми суперечки, які могли бути посилені додатковими накладними накладними накладними рівнями ізоляції знімків, коли база даних знаходиться в групі доступності. Це, можливо, мало або нічого спільного з вашими очікуваннями HADR_SYNC_COMMIT.

Якщо ви хочете перевірити це, ви можете використовувати розширений слід події, який дивиться на hadr_db_commit_mgr_update_harden XEvent у вашій основній репліку і отримати базову лінію. Отримавши базову лінію, ви зможете додавати свої репліки по одній по одній і бачити, як змінюється слід. Настійно рекомендую вам використовувати файл, розміщений на томі, який не містить баз даних, і встановити перекидання та максимальний розмір. Будь ласка, відрегулюйте фільтр тривалості за необхідністю для збору подій, які відповідають вашим очікуванням, щоб ви могли надалі усунути неполадки та співвіднести це з будь-якими іншими командами, які потребують участі.

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO