Есть кластер серверов БД SQL Server 2016 SP1 Enterprise (13.0.4001.0) и группа доступности в asynchronous-commit режиме.
Возникают проблемы с задержками репликации на secondary ноды при большом количестве изменённых данных на primary ноде.
Например, index rebuild или обновление большого кол-ва строк, которые на primary ноде выполняются за 30 секунд, на secondary ноду могут "приехать" с задержкой 10 минут.
"Железо" хорошее, мощное, одинаковое на всех нодах. Проблем с загрузкой "железа" на secondary нодах нет.
Ошибок, блокировок, дедлоков на secondary нодах во время отставания репликации нет.
В perfmon на всех secondary нодах примерно одинаковое максимальное пиковое значение "Redone Bytes/sec" - порядка 55 мегабайт/сек.
"Log Bytes Recived/sec" и "Log Bytes Decompressed/sec" (если включена компрессия) - в разы больше чем "Redone Bytes/sec".
После массовых изменений на primary копится большая Redone queue на secondary.

Пробовал:
1) alter endpoint encryption = disabled для endpoints, через которые работает AlwaysOn - не помогло.
2) включать trace flag T1462 (Disables log stream compression for asynchronous availability groups) - не помогло.
3) включать trace flag T9591 (Disables log block compression in Always On Availability Groups) - не помогло.
4) отключать hyperthreading - не помогло.

Вот здесь вот ( http://www.sqlsaturday.com/SessionDownload.aspx?suid=12181) пишут:
SQL Server 2012 single threaded redo - ~45MB/sec
SQL Server 2016 multi-threaded redo - ~600MB/sec
Хотя непонятно что именно значат эти цифры и откуда их взяли

А вот здесь ( https://www.sandisk.com/content/dam/sandisk-main/en_us/assets/resources/enterprise/white-papers/sql-server-2016-ags-on-hpe-dl380-gen9-using-hpe-12g-sas-2.5in-ssds-wp.pdf) пишут:
...However, limitations to AG secondary log redo remain the system bottleneck. The challenge is that a singlethreaded
process is still being used to distribute work to the threads that actually implement redo...
...In the context of this three-replica configuration ...
There are challenges related to AG log redo. As expected, the AG secondary’s % Processor Time is lower, here
only 7%. The secondary is responsible merely for applying log traffic, hardened on its replica database log, to the
database data files. However, the explanation for the secondary’s 17K Transactions/sec—a fraction of the
primary’s 71K transaction rate—is because of internal constraints: the SQL Server 2016 RTM log redo cannot
restore log traffic as quickly as the data is received from the primary. Specifically, the value for secondary’s
Redone Bytes/sec is only 51 MB/sec. As stated previously, the secondary’s Bytes Received from
Replica/sec is 213 MB/sec. The delta between log traffic received (213 MB/sec) and log data redone (51
MB/sec) is 162 MB/sec. This delta is reflected in the secondary’s Recovery Queue average value of 68 million log
records, as well as the growth highlighted in the graphic below...
...the DB STARTUP processes waiting for CPU cycles in order to provide work to idle redo
threads.
The SQL Server product team is working to remediate the AG log redo bottleneck...

Т.е. заявленная в SQL Server 2016 многопоточность AlwaysOn - не совсем многопоточность.
На каждую БД есть один процесс DB STARTUP который распределяет нагрузку до 16 потоков PARALLEL_REDO на одну БД.
И этот процесс DB STARTUP является bottleneck.

Большое отставание на secondary нодах для нас неприемлемо.
Что можно попробовать сделать чтобы ускорить репликацию?
Какие есть workaround кроме разделения БД на несколько?