# 30.4.异步提交
异步提交是一种选项,允许事务更快地完成,而代价是,如果数据库崩溃,最新的事务可能会丢失。在许多应用中,这是一个可接受的权衡。
如前一节所述,事务提交通常是同步:服务器等待事务的WAL记录刷新到永久存储,然后再向客户端返回成功指示。因此,客户机可以保证报告提交的事务将被保留,即使在服务器崩溃之后立即发生。但是,对于短事务,此延迟是总事务时间的主要组成部分。选择异步提交模式意味着服务器在逻辑完成事务后,即返回成功,然后生成的WAL记录实际上已经到达磁盘。这可以为小事务提供显著的吞吐量提升。
异步提交会带来数据丢失的风险。在提交给客户机的事务完成报告和真正提交事务的时间之间有一个短时间窗口(即,如果服务器崩溃,保证不会丢失)。因此,如果客户机将根据将记住事务的假设采取外部操作,则不应使用异步提交。例如,银行肯定不会使用异步提交来记录ATM分配现金的交易。但是在许多场景中,例如事件日志,不需要对这种情况有强有力的保证。
使用异步提交所带来的风险是数据丢失,而不是数据损坏。如果数据库崩溃,它将通过将WAL重新播放到刷新的最后一条记录来恢复。因此,数据库将恢复到自一致状态,但尚未刷新到磁盘的任何事务都不会反映在该状态中。因此,净影响是最后几笔交易的损失。因为事务是按提交顺序重放的,因此不能引入不一致性——例如,如果事务B依赖于前一个事务a的影响进行更改,则在保留B的影响的同时,a的影响不可能丢失。
用户可以选择每个事务的提交模式,以便同步和异步提交事务都可以同时运行。这允许在性能和事务持久性确定性之间灵活权衡。提交模式由用户设置参数控制同步_犯罪,可以通过设置配置参数的任何方式更改该参数。用于任何一个事务的模式取决于同步提交
当事务提交开始时。
例如,某些实用程序命令升降台
,则无论同步提交
。这是为了确保服务器的文件系统和数据库的逻辑状态之间的一致性。支持两阶段提交的命令,例如准备交易
,也总是同步的。
如果数据库在异步提交和写入事务的WAL记录之间的风险窗口期间崩溃,则在该事务期间进行更改将迷路了。风险窗口的持续时间是有限的,因为后台进程(“WAL编写器”)会将未写入的WAL记录刷新到磁盘上沃尔_作家_延迟毫秒。风险窗口的实际最长持续时间是三倍沃尔_作家(wal_delay)
因为WAL writer的设计倾向于在繁忙时期一次书写整页。
# 小心
立即模式关闭相当于服务器崩溃,因此会导致任何未刷新的异步提交丢失。
异步提交提供与设置不同的行为同步关。同步
是一个服务器范围的设置,将改变所有事务的行为。它会禁用PostgreSQL中尝试同步写入数据库不同部分的所有逻辑,因此系统崩溃(即硬件或操作系统崩溃,而不是PostgreSQL本身的故障)可能会导致数据库状态的任意严重损坏。在许多情况下,异步提交提供了通过关闭同步
,但没有数据损坏的风险。
犯罪_延迟听起来也很像异步提交,但它实际上是一种同步提交方法(实际上,推迟
在异步提交期间被忽略)。推迟
在事务将WAL刷新到磁盘之前导致延迟,希望一个这样的事务执行的单个刷新也可以同时为其他提交的事务服务。该设置可以被认为是一种增加时间窗口的方法,在该时间窗口中,交易可以加入一个即将参与单一冲销的组,以便在多个交易中分摊冲销成本。