AUTO: Docs repo sync - ScalarDB

i18n/versioned_docs/ja-jp/docusaurus-plugin-content-docs/current/scalardb-cluster/remote-replication.mdx

@@ -459,7 +459,12 @@ helm install <HELM_RELEASE_NAME> scalar-labs/scalardb-cluster \
 kubectl logs <PRIMARY_POD_NAME> -n <NAMESPACE>
 ```
 
-`<PRIMARY_POD_NAME>` を実際の Pod 名に置き換えてください。エラーがないことを確認してください。
+`<PRIMARY_POD_NAME>` を実際の Pod 名に置き換えてください。エラーがない場合、LogWriter が適切に初期化されたことを示すメッセージが表示されます:
+
+```console
+2025-07-03 08:56:10,162 [INFO  com.scalar.db.cluster.replication.logwriter.LogWriterSnapshotHook] LogWriter is initialized
+```
+
 
 #### 2.3 プライマリサイトテーブルの作成
 
@@ -874,6 +879,72 @@ kubectl delete -f sql-cli-primary.yaml -n <NAMESPACE>
 kubectl delete -f sql-cli-backup.yaml -n <NAMESPACE>
 ```
 
+### ステップ 5: レプリケーション状態の監視
+
+このステップでは、Replication CLI と Prometheus メトリクスを使用してレプリケーション状態を監視します。
+
+#### Replication CLI
+
+Replication CLI は LogApplier の状態を取得できます。これには、レプリケーションデータベース内の残りの未適用の書き込み操作を含むパーティション数が含まれます。この情報は重要です。なぜなら、パーティション数がゼロの場合、すべての書き込み操作が正常にレプリケートされ、バックアップサイトデータベースに適用されたことを意味するからです。この場合、同期されたバックアップサイトデータベースを新しいプライマリサイトデータベースとして使用できます。
+
+バックアップサイト用に Replication CLI を実行する Kubernetes Pod を作成します:
+
+```yaml
+# repl-cli-backup.yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: repl-cli-backup
+spec:
+  restartPolicy: Never
+  containers:
+  - name: repl-cli-backup
+    image: ghcr.io/scalar-labs/scalardb-cluster-replication-cli:<VERSION>
+    args:
+      - "--contact-points"
+      - "<BACKUP_CLUSTER_CONTACT_POINTS>"
+      - "status"
+```
+
+`<BACKUP_CLUSTER_CONTACT_POINTS>` をバックアップサイトクラスター接続ポイント ([ScalarDB Cluster のクライアント設定](scalardb-cluster-configurations.mdx#クライアント設定)と同じ形式)に、`<VERSION>` を使用している ScalarDB Cluster のバージョンに置き換えてください。
+
+正確な同期ポイントを取得するために、プライマリサイトデータベースに新しい書き込みが行われていないことを確認してください。その後、Replication CLI を適用して実行し、出力を確認します:
+
+```bash
+# Pod を適用
+kubectl apply -f repl-cli-backup.yaml -n <NAMESPACE>
+
+# 状態を確認
+kubectl get pod repl-cli-backup -n <NAMESPACE>
+
+# Pod からの出力を確認
+kubectl logs repl-cli-backup -n <NAMESPACE>
+```
+
+正常に処理された場合、レプリケーションデータベース内において未適用の書き込み操作が残っているパーティション数が JSON 形式で出力されます:
+
+```json
+{"remainingTransactionGroupPartitions":0}
+```
+
+`remainingTransactionGroupPartitions` が0より大きい場合、未適用の書き込み操作がまだ残っていることを示しており、バックアップサイトデータベースを新しいプライマリデータベースとして使用する前に、この値が0になるまで待つ必要があります。
+
+完了後、Replication CLI Pod をクリーンアップします:
+
+```bash
+kubectl delete -f repl-cli-backup.yaml -n <NAMESPACE>
+```
+
+#### Prometheus メトリクス
+
+メトリクスを使用して LogApplier を監視できます。ScalarDB Cluster は LogApplier メトリクスを含む多くの Prometheus 形式のメトリクスを公開しており、この形式をサポートする任意のツールで監視できます。例えば、[Prometheus Operator (kube-prometheus-stack)](helm-charts/getting-started-monitoring.mdx) を使用するという選択肢があります。
+
+LogApplier は多くのメトリクスを提供しますが、レプリケーション全体の健全性を監視するために最も重要なメトリクスは以下の通りです:
+
+- **scalardb_cluster_stats_transaction_group_repo_oldest_record_age_millis:** LogApplier によってスキャンされたレプリケーションデータベース内の最古のトランザクションデータの経過時間(ミリ秒)。このメトリクスが継続的に増加している場合、以下のいずれかの問題を示しており、即座に調査が必要です:
+  - LogApplier が保存された書き込み操作の処理に失敗している (例: バックアップサイトデータベースがダウンしている)。
+  - LogApplier がプライマリサイトのスループットに追いつけない。
+
 ## 追加詳細
 
 リモートレプリケーションは現在プライベートプレビューです。この機能とドキュメントは変更される可能性があります。詳細については、[お問い合わせ](https://www.scalar-labs.com/contact)いただくか、この機能がパブリックプレビューまたは GA になるまでお待ちください。