All Secondary die, Primary hang? – SQL Server 2017 on Linux
关于AVAILABILITY_MODE 需要注意的是，与Oracle Data Guard不尽相同的概念是，在Always On AG中每个replica上都可以设置自己的AVAILABILITY_MODE。AVAILABILITY_MODE参数有三个可选值，分别是SYNCHRONOUS_COMMIT、ASYNCHRONOUS_COMMIT和CONFIGURATION_ONLY。 SYNCHRONOUS_COMMIT：同步提交，意味着主replica的事务必须等到备replica将变更日志写入磁盘中才可以提交。可以设置包括主replica在内的最多三个replica处于同步提交状态。 ASYNCHRONOUS_COMMIT：异步提交，意味着replica无需等待备replica的动作而可以直接提交成功。 CONFIGURATION_ONLY：仅同步AG配置元数据。设置为该值的replica仅会从主replica中将AF配置的元数据同步过来，不会同步任何用户表数据。 在一个多节点replica的AG环境中，如果： 主库和其中任何一个备库设置为SYNCHRONOUS_COMMIT，则主库的日志提交必须等待该备库完成日志写入； 主库设置为SYNCHRONOUS_COMMIT，而所有备库都设置为ASYNCHRONOUS_COMMIT，则主库无需等待； 主库设置为ASYNCHRONOUS_COMMIT，则无视备库上该参数的设置，主库均无需等待。 在多节点的AG环境中，假设一个主库配置了两个同步的secondary，那么是不是要等待这两个secondary都完成日志写入才能提交事务呢？此时又引入了required_synchronized_secondaries_to_commit参数。 关于required_synchronized_secondaries_to_commit required_synchronized_secondaries_to_commit参数是在SQL Server 2017中引入的，这个参数从直观意义上就可以看得出是指定当commit的时候需要有个几个同步的secondary replica存活。 这个参数在三节点的AG集群中，默认值为1，也就是如果至少要存活一个secondary replica，主库上的事务才可以提交，否则commit就会一直等待。这很好理解。但是不好理解的是，该参数可以手工修改为0，从字面上看应该是说，即使所有secondary replica都不同步了，也是可以允许commit的。 但是实际情况却并非如此，修改为0是不起作用的。通过以下测试可以知道。 首先，设置required_synchronized_secondaries_to_commit参数为0 [shell] sudo pcs resource update ag_cluster…
