类型: | bool |
默认: | on |
上下文: | sighup |
重新开始: | false |
如果打开这个参数,PostgreSQL服务器将尝试确保更新被物理地写入到磁盘,做法是发出fsync()系统调用或者使用多种等价的方法(见wal_sync_method)。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。
虽然关闭fsync
常常可以得到性能上的收益,但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此,只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync
。
能安全关闭fsync
的环境的例子包括从一个备份文件中初始加载一个新数据库集簇、使用一个数据库集簇来在数据库被删掉并重建之后处理一批数据,或者一个被经常重建并却不用于失效备援的只读数据库克隆。单独的高质量硬件不足以成为关闭fsync
的理由。
当把fsync
从关闭改成打开时,为了可靠的恢复,需要强制在内核中的所有被修改的缓冲区进入持久化存储。这可以在多个时机来完成:在集簇被关闭时或在 fsync 因为运行initdb --sync-only而打开时、运行sync时、卸载文件系统时或者重启服务器时。
在很多情况下,为不重要的事务关闭synchronous_commit可以提供很多关闭fsync
的潜在性能收益,并不会有的同时, 关闭fsync可以提供很多潜在的性能优势,而不会有伴随着的数据损坏风险。
fsync
只能在postgresql.conf文件中或在服务器命令行上设置。如果你关闭这个参数,请也考虑关闭full_page_writes。
建议 [EN]
Never turn off unless your data is entirely disposable. Setting fsync=off is the equivalent of saying “I don't care about my data, I can recreate the database from scratch if I have to.” If synch activity is a performance concern, see synchronous_commit.
在 StackOverflow
在 pgsql-hackers
- Re: checkpointer: PANIC: could not fsync file: No such file or directory
- Re: Show WAL write and fsync stats in pg_stat_io
- Re: Fsync (flush) all inserted WAL records
- Re: recoveryCheck/008_fsm_truncation is failing on dodo in v14- (due to slow fsync?)
- recoveryCheck/008_fsm_truncation is failing on dodo in v14- (due to slow fsync?)