Skip to content

Commit

Permalink
update backup for 16.0
Browse files Browse the repository at this point in the history
  • Loading branch information
koizumistr committed Mar 26, 2024
1 parent 1ba0a00 commit 5883189
Showing 1 changed file with 22 additions and 44 deletions.
66 changes: 22 additions & 44 deletions doc/src/sgml/backup.sgml
Original file line number Diff line number Diff line change
Expand Up @@ -1053,11 +1053,9 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
directory). It is advisable to test your proposed archive library to ensure
that it does not overwrite an existing file.
-->
《マッチ度[69.711538]》通常アーカイブ用コマンドあるいはライブラリは、既存のアーカイブ済みファイルの上書きを行わないように設計されなければなりません。
通常アーカイブ用コマンドあるいはライブラリは、既存のアーカイブ済みファイルの上書きを行わないように設計されなければなりません。
これは、管理者のミス(例えば2つの異なるサーバの出力を同一のアーカイブ用ディレクトリに送信してしまうなど)といった場合からアーカイブ状況の整合性を保護するための安全策として重要です。
《機械翻訳》アーカイブコマンドとライブラリは、通常、既存のアーカイブファイルの上書きを拒否するように設計されている必要があります。
これは、管理者エラーのケースにあるアーカイブの整合性を維持するための重要な安全機能です(2つの異なるサーバの出力を同じアーカイブディレクトリに送信するなど)。
既存のファイルを上書きしないように、提案されたアーカイブライブラリを保証にテストすることをお勧めします。
確実に既存のファイルを上書きしないように、使用予定のアーカイブライブラリを試験することをお勧めします。
</para>

<para>
Expand All @@ -1074,10 +1072,10 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 &amp;&amp; cp pg_wal/0
archive command or library <emphasis>must</emphasis> return a nonzero status or
<literal>false</literal>, respectively.
-->
《機械翻訳》まれに、<productname>PostgreSQL</productname>は以前にアーカイブされたWALアーカイブを再ファイルしようとすることがあります。
たとえば、サーバが永続的なアーカイブの成功を記録する前にシステムがクラッシュした場合、サーバは再起動後にファイルを再びアーカイブしようとします(アーカイブがまだ有効になっている場合)。
アーカイブコマンドまたはライブラリが事前に存在するファイルに遭遇した場合、WALファイルの内容が事前に存在するアーカイブと同じであり、事前に存在するアーカイブがストレージに完全に永続化されている場合、それぞれ0のステータスまたは<literal>true</literal>を返す必要があります
事前に存在するファイルがアーカイブされるWALファイルと異なる内容を含む場合、アーカイブコマンドまたはライブラリは、それぞれ0のステータスまたは<literal>false</literal>を返す<emphasis>必要があります</emphasis>。
まれに、<productname>PostgreSQL</productname>は以前にアーカイブされたWALアーカイブを再ファイルしようとすることがあります。
たとえば、サーバがアーカイブの成功を永続的に記録する前にシステムがクラッシュした場合、サーバは再起動後にファイルを再びアーカイブしようとします(アーカイブがまだ有効になっている場合)。
アーカイブコマンドやライブラリが既に存在するファイルに遭遇した場合、WALファイルの内容が既に存在するアーカイブと同じであり、既に存在するアーカイブがストレージに完全に永続化されている場合、それぞれ0のステータス、<literal>true</literal>を返すことが必要です
既に存在するファイルがアーカイブされるWALファイルと異なる内容を含む場合、アーカイブコマンドやライブラリは、それぞれ0のステータス、<literal>false</literal>を返さ<emphasis>なければなりません</emphasis>。
</para>

<para>
Expand All @@ -1091,13 +1089,9 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 &amp;&amp; cp pg_wal/0
will return status zero when <option>-i</option> is used and the target file
already exists, which is <emphasis>not</emphasis> the desired behavior.)
-->
《マッチ度[50.180505]》使用予定のアーカイブ用コマンドあるいはライブラリが、当然のことながら既存のファイルを上書きしないこと、<emphasis>かつ、上書きしようとした場合には非ゼロのステータスあるいは<literal>false</literal>をそれぞれ返すこと</emphasis>を確認するために試験することを勧めます。
上のUnix用のコマンド例では、別途<command>test</command>という段階を含めることでこれを確認しています。
上のUnix用のコマンド例では、別途<command>test</command>という段階を含めることで、既に存在するアーカイブへの上書きを防いでいます。
いくつかのUnixプラットフォームでは<command>cp</command>コマンドには<option>-i</option> 引数を使うことで煩雑な出力を少なくし使うことができますが、正しい終了コードが返ることを確認せずに使用するべきではありません。
(具体的にはGNUの<command>cp</command>コマンドは<option>-i</option> オプションを使い、ターゲットファイルがすでに存在している場合、ゼロのステータスを返します。これは<emphasis>期待していない</emphasis>動作です。)
《機械翻訳》上記のUnix用の例コマンドは、別の<command>テスト</command>アーカイブを含めることで、既存のステップの上書きを回避します。
一部のUnixプラットフォームでは、<command>cp</command>に<option>-i</option>のようなスイッチがあり、同じことをあまり冗長に行うことができませんが、正しい終了ステータスが返されることを確認せずにこれらに依存すべきではありません。
(特に、GNU<command>cp</command>は、<option>-i</option>が使用され、ターゲットファイルがすでに存在する場合にステータスゼロを結果しますが、これは望ましい動作ではありません<emphasis>しません</emphasis>。)
</para>

<para>
Expand Down Expand Up @@ -1714,10 +1708,10 @@ GNUの <application>tar</application>で1.23以降のバージョンを使用し
subdirectory, as it might contain WAL files which
were not archived before the system went down.
-->
《マッチ度[90.143737]》もし容量があるのであれば、後で必要になる場合に備えてクラスタデータディレクトリ全体とテーブル空間を全て一時的な場所にコピーしてください。
もし容量があるのであれば、後で必要になる場合に備えてクラスタデータディレクトリ全体とテーブル空間を全て一時的な場所にコピーしてください。
この予防措置は、既存のデータベースを2つ分保持できるだけの空き領域を必要とします。
十分な領域がない場合でも、少なくともクラスタの<filename>pg_wal</filename>サブディレクトリの内容は保存すべきです。
ここには、システムが停止する前にアーカイブされなかったログファイルが含まれているかも知れないからです
ここには、システムが停止する前にアーカイブされなかったWALファイルが含まれているかも知れないからです
</para>
</listitem>
<listitem>
Expand Down Expand Up @@ -1837,19 +1831,13 @@ GNUの <application>tar</application>で1.23以降のバージョンを使用し
character in the command. The simplest useful command is
something like:
-->
《マッチ度[]》ここで重要となるのは、どのように復旧させたいのかやどこまで復旧させたいかを記述する復旧設定を設定することです。
ここで重要となるのは、どのように復旧させたいのかやどこまで復旧させたいかを記述する復旧設定を設定することです。
絶対に指定しなければならないことは、アーカイブ済みWALファイルセグメントをどのように戻すかを<productname>PostgreSQL</productname>に通知する<varname>restore_command</varname>です。
<varname>archive_command</varname>同様、これはシェルコマンド文字列です。
ここには、対象のログファイルの名前で置換される<literal>%f</literal>やログファイルのコピー先を示すパスで置換される<literal>%p</literal>を含めることができます。
ここには、対象のWALファイルの名前で置換される<literal>%f</literal>やWALファイルのコピー先を示すパスで置換される<literal>%p</literal>を含めることができます。
(パス名は現在の作業用ディレクトリ、つまり、クラスタのデータディレクトリから見た相対パスです。)
コマンド内に<literal>%</literal>文字自体を埋め込む必要があれば<literal>%%</literal>と記載してください。
最も簡単でよく使われるコマンドは以下のようなものです。
《機械翻訳》このすべての重要な部分は、リカバリの設定を設定することです。この設定では、リカバリの方法と、リカバリをどの程度実行するかを指定します。
絶対に指定する必要があるのは、<varname>restore_command</varname>です。これは、<productname>PostgreSQL</productname>にアーカイブされたWALファイルセグメントを取得する方法を指定します。
<varname>archive_command</varname>と同様、これはシェルコマンド文字列です。
<literal>%f</literal>を含むことができます。 これは、目的のWALファイル名で置き換えられます。 <literal>%p</literal>は、WALファイルのコピー先パス名で置き換えられます。
(パス名は、現在の作業ディレクトリ、つまりクラスタのデータディレクトリに対する相対パスです。) 実際の<literal>%</literal>文字をコマンドに埋め込む必要がある場合は、<literal>%%</literal>を書きます。
最も単純で役に立つコマンドは、次のようなものです。
<programlisting>
restore_command = 'cp /mnt/server/archivedir/%f %p'
</programlisting>
Expand Down Expand Up @@ -2040,11 +2028,11 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
in other contexts, such as server log messages, timeline IDs are
usually printed in decimal.)
-->
《機械翻訳》この問題に対処するために、<productname>PostgreSQL</productname>には<firstterm>タイムライン</firstterm>という概念があります。
アーカイブリカバリが完了すると、 そのリカバリ後に生成されたWALレコードのシリーズを識別するために、 新しいタイムラインが作成されます
タイムラインID番号はWALセグメントファイル名の一部なので、新しいタイムラインは以前のタイムラインによって生成されたWALデータを上書きしません
たとえば、WALファイル名 <filename>0000000100001234000055CD</filename>の場合、先頭の <literal>00000001</literal>は16進数でのタイムラインIDです。
他のコンテキストでは、たとえばサーバログメッセージの場合、タイムラインIDは通常10進数で表示されます。)
こうした問題を扱うために<productname>PostgreSQL</productname>には<firstterm>タイムライン</firstterm>という概念があります。
アーカイブ復旧が完了したときはいつでも、その復旧後に生成されたWAL記録を識別するための新しいタイムラインが生成されます
タイムラインID番号はWALセグメントファイル名の一部です。ですので、新しいタイムラインはこれまでのタイムラインで生成されたWALデータを上書きしません
たとえば、WALファイル名が<filename>0000000100001234000055CD</filename>の場合、先頭の<literal>00000001</literal>は16進数でのタイムラインIDです。
たとえばサーバログメッセージのような他のコンテキストの場合、タイムラインIDは通常10進数で表示されることに注意してください。)
</para>

<para>
Expand All @@ -2059,22 +2047,12 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
timelines, you can recover to <emphasis>any</emphasis> prior state, including
states in timeline branches that you abandoned earlier.
-->
《マッチ度[]》こうした問題を扱うために<productname>PostgreSQL</productname>には<firstterm>タイムライン</firstterm>という概念があります。
アーカイブ復旧が完了したときはいつでも、その復旧後に生成されたWAL記録を識別するための新しいタイムラインが生成されます。
タイムラインID番号はWALセグメントファイル名の一部です。
ですので、新しいタイムラインはこれまでのタイムラインで生成されたWALデータを上書きしません。
実際、多くの異なるタイムラインをアーカイブすることができます。
不要な機能と考えるかもしれませんが、命綱になることがしばしばあります。
どの時点まで復旧すればよいか確実でないといった状況を考えてみてください。
その時は、過去の履歴からの分岐点として最善の時点を見つけるために、試行錯誤して何度もポイントインタイムの復旧を行う必要があるでしょう。
タイムラインがないと、この手続きはすぐに管理不能な混乱を招いてしまいます。
タイムラインを使用して、以前捨てたタイムライン分岐における状態を含む、過去の<emphasis>任意</emphasis>の状態に復旧させることができます。
《機械翻訳》実際、多くの異なるタイムラインをアーカイブすることは可能です。
それは役に立たない機能のように見えるかもしれませんが、多くの場合、命の恩人です。
どのシチュエーションにリカバリするかわからないポイントを考えてみてください。
そのため、古い歴史からブランチオフへのベストの場所を見つけるまで、試行とエラーによっていくつかのポイント・イン・タイム・リカバリを行う必要があります。
タイムラインがなければ、このプロセスはすぐに手に負えない混乱を引き起こします。
タイムラインを使用すると、以前に放棄したタイムライン支店の州を含め、<emphasis>任意の</emphasis>以前の州にリカバリできます。
</para>

<para>
Expand Down Expand Up @@ -2322,9 +2300,9 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
the best practice is to take a new base backup after creating or
dropping tablespaces.
-->
《マッチ度[90.264026]》<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>コマンドはリテラルの絶対パス付でWALにログが記録され、したがって、同じ絶対パスでのテーブル空間作成の時に再生されます。
これは、もしログが異なったマシン上で再生される場合には好ましくありません
ログ再生がたとえ同一のマシンであっても、新規のデータディレクトリであれば危険です。
<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>コマンドはリテラルの絶対パス付でWALにログが記録され、したがって、同じ絶対パスでのテーブル空間作成の時に再生されます。
これは、もしWALが異なったマシン上で再生される場合には好ましくありません
WAL再生がたとえ同一のマシンであっても、新規のデータディレクトリであれば危険です。
なぜなら、再生は元のテーブル空間の内容を上書きし続けるからです。
この種の潜在的な振舞いを防ぐためには、テーブル空間を作成もしくは削除後に新規ベースバックアップを行うのが最良の手段です。
</para>
Expand All @@ -2351,13 +2329,13 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
of page snapshots included in WAL by increasing the checkpoint
interval parameters as much as feasible.
-->
《マッチ度[91.916168]》また、デフォルトの<acronym>WAL</acronym>フォーマットは数多くのディスクページのスナップショットを含んでいるため、かなりかさばるものになってしまっていることに触れておくべきでしょう。
また、デフォルトの<acronym>WAL</acronym>フォーマットは数多くのディスクページのスナップショットを含んでいるため、かなりかさばるものになってしまっていることに触れておくべきでしょう。
これらのページスナップショットは、クラッシュから回復のために設計されています。
それというのも、回復処理の際には不完全に書き込まれているディスクページを修復しなければならないことがあるからです。
システムのハードウェアやソフトウェアによっては、不完全なディスクページの書き込みが起きてしまう危険性は無視してもよい程微小です。
この場合<xref linkend="guc-full-page-writes"/>パラメータを設定してページスナップショットを無効にすることで、アーカイブされたログの総容量を大幅に縮小できます
この場合<xref linkend="guc-full-page-writes"/>パラメータを設定してページスナップショットを無効にすることで、アーカイブされたWALの総容量を大幅に縮小できます
(実際に設定を行う前に、<xref linkend="wal"/>の注意事項と警告を読んでください)。
ページスナップショットを無効にしても PITR処理の際にログが使用できなくなることはありません
ページスナップショットを無効にしても PITR処理の際にWALが使用できなくなることはありません
将来の課題は、<varname>full_page_writes</varname>がたとえオンになっている場合であっても不要なページを取り除き、アーカイブ済みWALデータの圧縮を行うことでしょう。
差し当たり管理者は、可能な限りチェックポイント間隔パラメータを大きくすることによって、WALに含まれるページスナップショットの数を削減することができます。
</para>
Expand Down

0 comments on commit 5883189

Please sign in to comment.