はじめに

こんにちは、SAKURUGのKeitaです。
今回はCitusの推奨replica設定が2022年時点で変更されていたことについてお話していこうと思います。

本記事で話す内容

1.Citusで非推奨となったreplica設定

2.Citusの推奨されるreplica設定

上記についてお話します。
今回、Citus自体については説明しないので、そもそもCitusとは？といった方は他の方のCitusに関する記事をご確認ください。

1.Citusで非推奨となったreplica設定

現在Webブラウザで確認できるCitusに関する日本語の記事では以下の記載が非常に多いです。

異なるWorker Node にレプリカを作成可能citus.shard_replication_factor （デフォルト値 1 ＝ レプリカを作らない）

このcitus.shard_replication_factorという設定、バージョン11以降からOSSコミュニティおよび公式の記事にて非推奨となっていることが明言されています。※詳細は参考記事を参照
では現在ではどういった設定でreplicaするのか、次の内容で確認しましょう。

2.Citusのreplica設定の現状

現在、Citusでサポートされたreplica設定は存在しません。
というのもCitus公式ドキュメントより以下の内容の記載があります。

Citus はワーカーノードの障害をどのように処理しますか?

Citus は PostgreSQL のストリーミングレプリケーションを使用して、ワーカーノード全体をそのまま複製します。ワーカーノードの WAL レコードをスタンバイノードに継続的にストリーミングすることで、ワーカーノードを複製します。オンプレミスでストリーミングレプリケーションを設定するには、PostgreSQL のレプリケーションドキュメントを参照してください。
※原文は英語。

以上の通り、Citusは既にPostgreSQLのストリーミングレプリケーションを使用して、ワーカーノードそのもののreplicaを作成することを推奨しています。
ただ文字だけで言われても分かりにくいと思うので実際にこれまでのイメージ図と現在のイメージ図で比較しましょう。

●従来と現在のイメージ図比較

・従来のイメージ
従来は以下イメージ図のように、1つのWorker内に他のWorkerのデータをコピーしているイメージ。

・現在のイメージ

現在は以下イメージ図のように、1つのWorkerにつき2つ以上のインスタンスを作成しプライマリとセカンダリに分ける。
プライマリのデータをWALを使用してセカンダリにコピーするイメージ。

と、上記のような差異があります。
また従来のやり方だと障害発生時が発生し元のデータにアクセスできなくなった際に
replicaが存在していても更新などが行えません。

それに対し現在の方法だとWorkerのプライマリ・スタンバイの切り替えさえ行えば更新等は行えます。
またWALを用いたデータ同期を行うため復旧後にデータの同期をとることも容易です。

終わりに

ここまで、お読みいただきありがとうございました。
そもそもストリーミングレプリケーションってなに？といった話はまた別途作成しようと思うのでお待ちいただければと思います。

今後もバックエンドをメインに記事を発信していくので、時々記事を見に来ていただけると嬉しいです。

※参考記事

OSSコミュニティ
Citus公式で非推奨となった記事