Что за технология?
Если кластер уже есть, лучше always on.

Смотря для каких целей, FCL гарантирует сохранность всех транзакций на реплике, AO не гарантирует даже в синхронном режиме.

msLex,

Ну основываясь на своих скудных знаниях работы AO, предполагаю такой ход событий:

Дано: нода1 с прямым сетевым соединением с нода2, есть свидетель на другом сетевом интерфейсе.

Теряется прямая связь между нодой1 и нодой2, свидетель в это время видит, что обе ноды доступны, как я понимаю, в этот момент нода1 остается праймари и все транзакции, которые должна закомитить на ноде2 попадают в некий "пул", ожидая, что связь восстановится и AO распространит эти транзакции на вторичной реплике, при этом, первичная реплика будет ставить коммит транзакций, как в асинхронном режиме. В этот момент нода1 выходит из строя, свидетель делает первичной ноду2, где этих транзакций не будет.

msLex,
Не уверен в этом:

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-2017

авторIf primary's session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

The default session timeout period is 10 seconds.


Те, если нода1 перестает видеть нода2 в течении 10 секунд, нода1 начинает коммитить транзакции.

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

Те, вся синхронность на этом заканчивается, свидетель не знает в каком состоянии находятся транзакции и сделает первичной ноду2, которая на этот момент уже работает в асинхронном режиме, те на ноде2 этих транзакций не будет.

С 2017го появился новый параметр REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, который не позволит зафиксировать транзакцию, пока она незакоммичена на одной из реплик.

Много в каких статьях встречался с упоминанием что синхронная репликация автоматически переключится на асинхронную, при отсутствии вторичной реплики, но нигде не видел упоминания, что свидетель в этом случае не переключит роль реплики на праймари, этого я сам не проверял.

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

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

Спасибо за информацию, НО
В случае, если первичная реплика при потере вторичной реплики перешла в асинхронный режим, а после вышла из строя, то на вторичной реплике этих данных не будет (хотя их мы считаем резервными), их можно считать потерянными, что в случае FCL исключено, так как в FCL нет репликаций, ноды используют одни данные на СХД.

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

Да, как раз хотел добавить UPD, что у FCL есть и свои минусы, как дороговизна, так и единая точка уязвимости в виде СХД, но только FCL может 100% гарантировать сохранность всех транзакций на резервной ноде.

Хотя, видел решения, где СХД реплицировалась в другой ДЦ, где на растянутом кластере жила отдельная нода, в случае потери СХД, данные должны были сохраниться.

СИБУР так пробовал обеспечить отказоустойчивость, одна СХД находится в Нижнем Новгороде, другая в Мск, но развязки я не застал.