あ @atsuchan@atsuchan.page

PostgreSQLのスタンバイサーバーを落としてしばらくしてから上げたけど、restore_commandにWALを取得するようにしておくと、自動的にリカバリして、スタンバイとして復帰してくれましたね
ストリーミングレプリケーションの状態はプライマリから監視して異常があればお知らせ・異常がにゃければheartbeatを送るようににゃってるので、いつの間にか死んでいたともにゃらにゃいはず

うちの大学からも東大の院に行く人、筑波の院に行く人がいますから、まあいろいろです

大学院はネームバリューよりも自分の研究したいことをやらせてもらえるかで決めるべきかにゃと思います。ある程度研究事項を決めていくと、ここの大学院でしかできにゃいみたいににゃってくるので、必然的に
あとは研究室訪問とかで様子を見る

@AureoleArk にゃるほどですね、PgBouncer自体を増やすとかも効果的にゃんでしょうか…

Fedora 36, Debian bullseye, CentOS7のSoftEtherで通してるから分からん…

メンテニャンスは許して欲しい（

@morotesovtannu えとねおはよう

@a え、マジで今起きたばっかりにゃのに、よく分かったね、おはよう

レプリカを強制再起動してみたけど、ロードバランサーもレプリケーション監視botも大丈夫そうですね

村上さんがPgpool-IIを通すとスループットが下がるって言ってたのと同じかしら

MisskeyでPGbouncer使うと極端にパフォーマンスが低下するにゃ、
最初サーバーのスペックの問題かと思ってマシン増やしたりしたんだけど、
これ単純にPGbouncer外すと高速化した

自宅サーバーマシンをさらにもう１台投入したけど軽くにゃったかしら

ちょっとサーバーもっさりしてたので
・Misskeyアプリケーションコンテニャのスケールアップ
・クラウドとオンプレミスを結んでいるトンネルの数を４本から６本に増強
・にゃるべくIPv6のトンネルを使うように設定
を実施しました

msk.ilnk.info にサーバー１台追加

んー自宅のメインサーバー重いねw
Mastodonのコンテニャをスケールアウトして別サーバーに移動したり、重くにゃってるMisskeyのコンテニャを再起動したり、アクセスの割り振りを変えたりして、改善を図ってます

@YuzuRyo61 確かに…めいすきー、misskey-v11とかに対応できるのはメリットですが、手間かかりますね