因为高可用必须是完整备份，所以日志就会越来越大。

平时收缩日志最简单粗暴的方法是 先把数据库设置为简单模式，然后收缩日志文件，然后再恢复为完整备份。

但是 高可用模式下，系统是无法设置为简单模式的。

所以采用一下方法（责任自负，后果自负）：以下操作在主库上进行操作,因为只有主副本可读可写.

step1:备份日志文件到空盘

BACKUP LOG myDatabaseName TO DISK='NUL:'

step2:查看日志状态

Use myDatabaseName
GO
dbcc loginfo

如果状态为 "2",执行 step3  

如果状态为"0",则可跳过Step3 直接执行Step 4

step3:带 EMPTYFILE 参数 执行收缩

DBCC SHRINKFILE (myDatabaseName_Log, EMPTYFILE);

step4:收缩日志文件到指定大小 以下单位为M.

DBCC SHRINKFILE (myDatabaseName_Log, 500);   –This would physically shrink the database size to 500 Megabytes.

 注意事项:

1 当日志无法收缩时,请确认副本数据库是否是正常状态,如果副库是可疑状态,则无法收缩成功. 如果是这种情况,可以删除可疑库再进行操作.

Note: Before determining the size of 500Mb to shrink to, you may want to consider how much of the log file is in use, otherwise the shrink operation will not work. Also, you may want to consider allowing the size of the log file to be 25% of the size of the physical database file (.MDF) because otherwise when log growth happens, the database operations will block all active transactions and that will cause latency within applications (imagine users complaining).

You can determine how much of the log file is in use by running this query:

Use myDatabaseName
GO

SELECT name ,size/128.0 – CAST(FILEPROPERTY(name, ‘SpaceUsed’) AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;

So to determine the size of the log file to shrink to, subtract the “AvailableSpaceInMB” from the physical database size reported by the command: DBCC SQLPERF(LOGSPACE);. Then add some cushion so that future physical log growth does not block transactions from occurring.

文章转自: https://www.thecloudtechnologist.com/shrinking-sql-log-files-in-an-availability-group-cluster-or-database-mirror/#:~:text=First%2C%20find%20out%20if%20your%20database%20is%20in,needed%2C%20switch%20the%20recovery%20model%20back%20to%20full.