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