ユーザ用ツール

サイト用ツール


it技術:データベース:postgresql:運用

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン前のリビジョン
次のリビジョン
前のリビジョン
次のリビジョン両方とも次のリビジョン
it技術:データベース:postgresql:運用 [2019/07/28 23:21] – [WALアーカイブからのリストア] yajuadminit技術:データベース:postgresql:運用 [2019/08/06 11:17] – [max_wal_size] yajuadmin
行 111: 行 111:
   * [[https://qiita.com/U_ikki/items/89b1eea657e47120e3ee|PostgreSQLのチェックポイント処理のチューニング]]   * [[https://qiita.com/U_ikki/items/89b1eea657e47120e3ee|PostgreSQLのチェックポイント処理のチューニング]]
  
 +==== wal_keep_segments ====
 +バックアップ後にpg_logに下記のエラーが発生
 +<code>
 +2019-08-06 02:18:35 JST ERROR:  requested WAL segment 000000010000005A000000D1 has already been removed
 +要求された wal セグメント * はすでに削除されています。
 +</code>
 +
 +対処として、wal_keep_segmentsをゼロ以外の値に設定する。\\
 +これは、ストリームの危険性が追いつかなくなるのを防ぐためです。\\
 +ただしpg_basebackupを使用する場合は、 – checkpoint = fastも忘れないでください。\\
 +https://codeday.me/jp/qa/20190609/972945.html
 +
 +<code>
 +#wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
 +
 +wal_keep_segments = 128
 +
 +backup.bat の見直し
 +pg_basebackup -U postgres -D "%bkPath%" -F t -x -z
 +
 +pg_basebackup -U postgres -D "%bkPath%" -F t -x -z --checkpoint=fast
 +</code>
 ===== データベース初期化 ===== ===== データベース初期化 =====
 ==== 全てのデータベース初期化 ==== ==== 全てのデータベース初期化 ====
行 297: 行 319:
 archive_timeoutはトランザクションがほとんど発生しない「なぎ」のとき、WALにたまった内容がいつまで経ってもアーカイブされないことを防ぐ。デフォルトでは0(機能無効) archive_timeoutはトランザクションがほとんど発生しない「なぎ」のとき、WALにたまった内容がいつまで経ってもアーカイブされないことを防ぐ。デフォルトでは0(機能無効)
  
 +archive_timeout = 60 とした場合、16MB*60回/時*24時間=23040MB/日≒23GB/日 が発生しうる。
 [[http://dbnote.web.fc2.com/note_param_pitr_walarchive.html|archive_timeoutの意味]] [[http://dbnote.web.fc2.com/note_param_pitr_walarchive.html|archive_timeoutの意味]]
 ==== WALアーカイブの削除 ==== ==== WALアーカイブの削除 ====
行 302: 行 325:
  
 pg_basebackup を実行すると、WALアーカイブのフォルダに拡張子backupが作成される。\\ pg_basebackup を実行すると、WALアーカイブのフォルダに拡張子backupが作成される。\\
-これにより指定した拡張子backupより前の不要なWALアーカイブ削除される。+これにより指定した拡張子backupより前の不要なWALアーカイブ削除される。
  
 <code> <code>
行 322: 行 345:
 よって、不要なWALアーカイブの削除は手動で行うこととする。\\ よって、不要なWALアーカイブの削除は手動で行うこととする。\\
 ※postgreSQLサービスを再起動すればリカバリが実行され、recovery.confはrecovery.doneになります。 ※postgreSQLサービスを再起動すればリカバリが実行され、recovery.confはrecovery.doneになります。
-==== WALアーカイブからのリストア ==== +==== WALアーカイブからのリカバリ ==== 
-[[http://ossfan.net/setup/postgresql-37.html|PostgreSQL 9.6.3で時刻指定のPITR(Point In Time Recovery)を実行する]]+リストアとリカバリとは区別しないで使うときもあるが、今回は分けました。 
 + 
 +  * リストアはバックアップデータを、バックアップを取ったときと同じ状態に物理的に復元すること 
 +  * リカバリはリストアしたデータに何かの処理をして最新の状態や正常な状態に復旧させること 
 + 
 +=== PITRの仕組み === 
 +PITR(Point In Time Recovery)は、WALレコード適用によるリカバリが前提となっている。 
 +  [[http://ossfan.net/setup/postgresql-37.html|PostgreSQL 9.6.3で時刻指定のPITR(Point In Time Recovery)を実行する]] 
 +  * [[http://blog.poppypop.mydns.jp/2016/03/03/postgresql_onlinebackup_recovery/|PostgreSQLのオンラインバックアップとリカバリ]] 
 + 
 +**WALレコードの適用までの流れ**\\ 
 +リカバリを開始してWALレコードを適用するまでの流れは次のようになっている。 
 + 
 +  - pg_controlファイルを読み込む 
 +  - recovery.confを読み込む 
 +  - backup_labelを読み込む 
 +  - pg_controlファイルを更新し、backup_labelを削除する 
 +  - 必要なWALを繰り返し適用する 
 + 
 +※backup_labelファイルから適用を開始すべきWALの位置を取得できなかった場合は、pg_controlファイルの情報を元にリカバリを開始します。
  
 +pg_controlファイルは、バイナリファイルなので通常のエディタでは内容を確認できません。そのために pg_controldata コマンドが用意されています。\\
 pg_controldata コマンドで最終チェックポイントのREDO WALファイルが分かる。 pg_controldata コマンドで最終チェックポイントのREDO WALファイルが分かる。
  
it技術/データベース/postgresql/運用.txt · 最終更新: 2024/04/24 11:07 by yajuadmin