high-availability.sgmlのPostgreSQL 17.0対応

doc/src/sgml/high-availability.sgml

@@ -1479,8 +1479,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     <link linkend="hot-standby-conflict">recovery conflict</link> even when the
     standby is disconnected.
 -->
-《マッチ度[91.746032]》レプリケーションスロットは、以下のことを保証する自動的な方法を提供します。
-全てのスタンバイがWALセグメントを受け取るまでは、プライマリがWALセグメントを削除しないこと、また、スタンバイが接続していない際にも、<link linkend="hot-standby-conflict">リカバリの競合</link>が発生する可能性がある行をプライマリが削除しないこと、です。
+レプリケーションスロットは、以下のことを保証する自動的な方法を提供します。
+全てのスタンバイがWALセグメントを受け取るまでは、プライマリサーバがWALセグメントを削除しないこと、また、スタンバイが接続していない際にも、<link linkend="hot-standby-conflict">リカバリの競合</link>が発生する可能性がある行をプライマリが削除しないこと、です。
    </para>
    <para>
 <!--
@@ -1493,8 +1493,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     required, whereas replication slots retain only the number of segments
     known to be needed.
 -->
-《機械翻訳》レプリケーションスロットを使用する代わりに、<xref linkend="guc-wal-keep-size"/>を使用したり、<xref linkend="guc-archive-command"/>や<xref linkend="guc-archive-library"/>を使用してアーカイブにセグメントを保存したりすることで、古いWALセグメントの削除を防ぐことができます。
-これらの方法の欠点は、レプリケーションスロットが必要とされる数のセグメントしか保持しないのに対して、必要以上のWALセグメントを保持することが多いことです。
+レプリケーションスロットを使う代わりに、<xref linkend="guc-wal-keep-size"/>を使う、あるいは<xref linkend="guc-archive-command"/>または <xref linkend="guc-archive-library"/>を使用してセグメントをアーカイブに保存することによっても、古いWALセグメントの削除を防ぐことができます。
+これらの方法の欠点は、しばしば必要以上のWALセグメントを保持することで、これらに対してレプリケーションスロットは必要とされる数のセグメントしか保持しません。
    </para>
    <para>
 <!--
@@ -1503,9 +1503,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     being removed by vacuum, but provides no protection during any time period
     when the standby is not connected.
 -->
-《マッチ度[73.046875]》同様に、<xref linkend="guc-hot-standby-feedback"/>は、レプリケーションスロットを使用しない場合、関連する行がバキュームによって削除されることに対して保護しますが、スタンバイが接続されていない間は保護しません。
-レプリケーションスロットはこれらの欠点を克服します。
-《機械翻訳》同様に、レプリケーションスロットを使用しない<xref linkend="guc-hot-standby-feedback"/>自体は、関連する行がバキュームによって除去されることに対する保護を提供するが、ピリオドが接続されていないときは、スタンバイ中に保護を提供しない。
+同様に、<xref linkend="guc-hot-standby-feedback"/>は、レプリケーションスロットを使用しない場合、関連する行がバキュームによって削除されることに対して保護しますが、スタンバイが接続されていない間は保護しません。
    </para>
 
    <caution>
@@ -1517,8 +1515,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
      <xref linkend="guc-max-slot-wal-keep-size"/> can be used to limit the size
      of WAL files retained by replication slots.
 -->
-《機械翻訳》レプリケーションスロットは、サーバが非常に多くのWALセグメントを保持し、<literal>pg_wal</literal>に割り当てられたスペースを一杯にしてしまう可能性があることに注意してください。
-<xref linkend="guc-max-slot-wal-keep-size"/>は、レプリケーションスロットが保持するWALファイルのサイズを制限するために使用できます。
+レプリケーションスロットは、サーバが非常に多くのWALセグメントを保持し、<literal>pg_wal</literal>に割り当てられた領域を一杯にしてしまう可能性があることに注意してください。
+<xref linkend="guc-max-slot-wal-keep-size"/>は、レプリケーションスロットによって保持されるWALファイルのサイズを制限するために使用できます。
     </para>
    </caution>
 
@@ -2165,10 +2163,8 @@ PostgreSQLは、WALデータをすべてのスタンバイが安全に受信し
     <varname>synchronous_commit</varname> = <literal>off</literal>, otherwise those
     requests will wait forever for the standby to appear.
 -->
-《マッチ度[80.758017]》トランザクションの待機中にスタンバイサーバを再作成する必要がある場合、pg_backup_start()およびpg_backup_stop()を実行するコマンドを<varname>synchronous_commit</varname> = <literal>off</literal>であるセッション内で確実に実行してください。
+トランザクションの待機中にスタンバイサーバを再作成する必要がある場合、<function>pg_backup_start()</function>関数および<function>pg_backup_stop()</function>関数を<varname>synchronous_commit</varname> = <literal>off</literal>であるセッション内で確実に実行してください。
 さもないとこれらの要求はスタンバイに現れるまで永遠に待機します。
-《機械翻訳》トランザクションの待機中にスタンバイサーバを再作成する必要がある場合、makeは、関数<function>pg_backup_start()</function>と<function>pg_backup_stop()</function>が<varname>synchronous_commit</varname> = <literal>off</literal>で実行されていることを確認します。
-そうでない場合、これらの要求はスタンバイが現れるまで永遠に待機します。
    </para>
 
    </sect3>
@@ -2361,7 +2357,7 @@ WALアーカイブがプライマリとスタンバイで共有されるケー
     for failover. This can be done by following the steps described in
     <xref linkend="logical-replication-failover"/>.
 -->
-《機械翻訳》ロジカルレプリケーションスロットの同期化（<xref linkend="logicaldecoding-replication-slots-synchronization"/>を参照）を選択した後、前をスタンバイサーバに切り替えた場合、スタンバイサーバで同期化されたロジカルスロットがチェックの準備ができていれば、フェイルオーバーに切り替えることをお勧めします。
+論理レプリケーションスロットの同期（<xref linkend="logicaldecoding-replication-slots-synchronization"/>参照）を選択した場合、スタンバイサーバに切り替える前に、スタンバイサーバと同期している論理スロットがフェイルオーバーの準備ができていることを確認しておくことをおすすめします。
 これは、<xref linkend="logical-replication-failover"/>で説明されている手順に従って行うことができます。
    </para>
 
@@ -3510,14 +3506,10 @@ WALの再実行はトリガに基づいたものではありません。
     <structname>pg_statio_</structname> views, nor will associated
     <structname>pg_stat_database</structname> columns be incremented.
 -->
-《マッチ度[77.817531]》リカバリの間も累積統計システムはアクティブになります。
+リカバリの間も累積統計システムはアクティブになります。
 すべてのスキャン、読み取り、ブロック、インデックスの使用などは、スタンバイサーバにおいて正常に記録されます。
 しかし、WAL再生はリレーションやデータベース固有のカウンタを増加させません。
-つまり、再生はpg_stat_all_tables列(n_tup_insなど)を増加させませんし、起動プロセスによって実行された読み取りや書き込みもpg_statioビューで追跡されませんし、関連するpg_stat_database列も増加されません。
-《機械翻訳》統計処理の累積システムは、リカバリの間のアクティブです。
-すべてのスキャン、読み取り、ブロック、インデックスの使用状況などは、通常どおりスタンバイに記録されます。
-しかし、WALリプレイはインクリメントリレーションやデータベース特有のカウンタを使用しません。
-すなわち、リプレイは<structname>pg_stat_all_tables</structname>列をインクリメントせず<structfield>n_tup_ins</structfield>のように、スタートアッププロセスによって実行された読み込みや書き込みも<structname>pg_statio_</structname>ビューで追跡されず、関連する<structname>pg_stat_database</structname>列もインクリメントされません。
+つまり、再生は<structname>pg_stat_all_tables</structname>列(<structfield>n_tup_ins</structfield>など)を増加させませんし、起動プロセスによって実行された読み取りや書き込みも<structname>pg_statio_</structname>ビューで追跡されませんし、関連する<structname>pg_stat_database</structname>列も増加されません。
    </para>
 
    <para>