サーバー移転計画のためPostgreSQLのドキュメント類や公式コンテナの中身を目を皿のようにしてみている
レプリケーションユーザーのパスワード認証に失敗するのでよく見ると、/root/.pgpassに置くのが悪いらしい
それを避けるために、postgresユーザーでpg_basebackupを実行しないといけなくて、そのためにはAlpine Linuxだとsudoではなくgosuをつかうというところまで理解した

パスワード認証しなくても別のレイヤーで防御しているから問題ないのですけど、設定ミスとかいろいろありますから多層に防御したいのですよね。

@n1lsqn まるっとバックアップするのが目的なので、ストリーミングを採用する方向でやっています。

@n1lsqn ロジカルはバージョンアップデートができるという利点があるということなので悩みどころでしたが、設定項目の少ないストリーミングでまずやってみようという算段です。

@n1lsqn はい。手動です。自動で切り替えるのは自動フェイルオーバーと呼びます。これをしたければ別途ソフトウェアを用意する必要があります。オープンソースでは、Pgpool-II などで実装されているようです。
サブDBとアプリケーションサーバーが直接接続でき、メインDBがダウンしたけれども、サブDBやアプリケーションサーバーが問題なく継続稼動しているという障害の仕方が想定される場合、このような仕組みが利用できます。
そうでない場合は、別な死活監視の方法や、障害時の切り替え処理を考える必要があると思います。
https://www.pgpool.net/docs/latest/ja/html/runtime-config-failover.html

Postgresのレプリケーションを受信するサーバー用のコンテナ
https://github.com/yuriha-chan/postgres-replication-dest-docker

サーバー側のデータベースにコマンドを打つだけでミュートワードの統合はできるっぽい
（他のサーバーがだいたいアップデートを完了してから統合方法を見つける人）

select "user_profile"."userId", "registry_item"."value", "user_profile"."mutedWords", "registry_item"."value" || "user_profile"."mutedWords" from "user_profile" left join "registry_item" on "registry_item"."userId" = "user_profile"."userId" and "registry_item"."key" = 'mutedWords' where not "registry_item"."value" is null and "user_profile"."userId"='9g2o6eycu3';

   userId   |           value            |         mutedWords         |                       ?column?
------------+----------------------------+----------------------------+------------------------------------------------------
 9g2o6eycu3 | [["ここはソフトミュート"]] | [["ここはハードミュート"]] | [["ここはソフトミュート"], ["ここはハードミュート"]]

Misskey 2023.11アップデートおよびサーバー費用節約のための移転の進捗

Done
・プライバシーポリシーの改定
・OCI Ampere インスタンスの確保
・PostgreSQLのレプリケーションのドキュメントの確認
・Autosshによる接続の設計
・レプリケーションによるバックアップの確認
・ミュートワード統合SQLを書き検証
ToDo:
・独自改造の最新版マージ
・ステージング環境の移転の確認
・本番環境の移転

RE: https://misskey-square.net/notes/9mot6imeii

アバターデコレーションの追加は抑制的に行う予定です。
（非表示にする機能があるとはいえ、無秩序に追加すると見た目がかなりうるさくなってしまうので。）

RE: https://misskey-square.net/notes/9mrp5zhbba