From cf58088850e800b89062d451a337563e1b106ca7 Mon Sep 17 00:00:00 2001 From: Keisuke Kuroda <59189894+kiskk@users.noreply.github.com> Date: Mon, 9 Dec 2024 17:36:51 +0900 Subject: [PATCH] =?UTF-8?q?=E3=83=95=E3=82=A7=E3=82=A4=E3=83=AB=E3=82=AA?= =?UTF-8?q?=E3=83=BC=E3=83=90=E3=83=BC=E5=BE=8C=E3=81=AE=E5=BE=A9=E6=97=A7?= =?UTF-8?q?=E3=81=AB=E3=81=8A=E3=81=91=E3=82=8B=E3=80=8Cformer=20primary?= =?UTF-8?q?=20system=E3=80=8D=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E6=97=A5?= =?UTF-8?q?=E6=9C=AC=E8=AA=9E=E8=A8=B3=E4=BF=AE=E6=AD=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 元の文では「former primary system」となっている箇所が「以前のプライマリサーバ」と訳されています。 このため、ストリーミングレプリケーションを構成していた「以前のプライマリサーバ」であるPostgreSQLが起動できれば、そのままスタンバイとして使えるようにも読めてしまいます。 実際には、フェイルオーバが起きたプライマリをそのまま利用するとデータ矛盾が発生する可能性があるため、 再構築するか、pg_rewindを用いて巻き戻す必要があります。 「以前のプライマリシステム」、つまりプライマリが稼働していたサーバやVMが現在も利用可能な状態であれば、 そのシステム上でスタンバイを再作成できる、ということを示している認識です。 元の文にならって、「プライマリシステム」に書き換えるとともに、スタンバイサーバの再作成が必要であることを明示的に示した方がわかりやすいと考えました。 --- doc/src/sgml/high-availability.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 1c7847151b1..2b469238441 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -2318,7 +2318,7 @@ WALアーカイブがプライマリとスタンバイで共有されるケー これは縮退状態と呼ばれます。 以前のスタンバイサーバはプライマリサーバになり、以前のプライマリは停止し、その後も停止し続けるかもしれません。 通常の運用に戻すには、スタンバイサーバを再作成しなければなりません。 -以前のプライマリサーバが起動できれば、これを使用しても構いませんし、第三のおそらく新規のシステムを使用しても構いません。 +以前のプライマリシステムが起動できればこのシステム上で再作成してもかまいませんし、第三のおそらく新規のシステム上で再作成してもかまいません。 を使って、大きなクラスタにおける処理を早めることもできます。 完了すれば、プライマリとスタンバイの役割が切り替わったとみなすことができます。 新しいスタンバイサーバを再作成するまでに第三のサーバを使用して新しいプライマリのバックアップを提供することを選択する人もいますが、これがシステム構成と運用手順を複雑にすることは明らかです。