タイプ: | bool |
デフォルト: | on |
コンテキスト: | sighup |
再起動: | false |
このパラメータがオンの場合、PostgreSQLサーバはfsync()システムコールを発行するか、もしくはこれに相当する方法(wal_sync_methodを参照)で、更新が物理的にディスクに確実に書き込まれるように試みます。これは、オペレーティングシステムもしくはハードウェアがクラッシュした後、データベースクラスタを一貫した状態に復旧させることを確実にします。
fsync
を停止することはしばしば性能上の利益になるとは言っても、停電やクラッシュの際に回復不可能なデータ破壊になることがあります。従って外部データから全てのデータベースを簡単に再構築できる場合のみfsync
を停止してください。
fsync
を停止しても安全な状況の例としては、以下があげられます。バックアップファイルから新しいデータベースクラスタにデータの初期読み込みを行う場合、バッチデータの処理のためにデータベースクラスタを使用し、その後データベースを削除して再構築する場合、読み込み専用のデータベースのクローンを頻繁に再作成するが、それをフェイルオーバーに使用しない場合、などです。高性能なハードウェアであるからと言って、fsync
を停止することは正当性を主張する十分な理由とはなりません。
fsync
を無効(off)から有効(on)に変更したときの信頼できるリカバリのためには、カーネル内の全ての変更されたバッファを恒久的ストレージに強制的に吐き出させることが必要です。これは、クラスタがシャットダウンしている間、またはfsync
が有効のときに、initdb --sync-onlyを実行する、syncを実行する、ファイルシステムをアンマウントする、またはサーバを再起動することによって可能となります。
多くの場合、重要でないトランザクションに対してsynchronous_commitを無効にすることにより、データ破壊という付随的危険性を伴うことなく、fsync
を無効にすることで得られるであろう性能上のメリットの多くを得ることができます。
fsync
はpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。このパラメータを無効にする場合、full_page_writesも同時に無効にすることを検討してください。
推奨事項 [EN]
On StackOverflow
On 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?)