Railsの中でスレッド処理をしていないのであれば
1スレッドの数ざっくりいうと、Unicornはマルチプロセスで、Pumaはマルチスレッドだから (厳密には違うけど)
それで、コネクションプールはRailsのプロセスごとに持ってる
マルチプロセスのUnicornでは、1worker = 1プロセス なので、workerが消費するのは、1つのコネクションだけ。
なので、database.ymlの pool の値は 1 が適正
それに対して、マルチスレッドのPumaでは、1つのプロセスで複数のスレッドが動作する。 そのため、スレッドの数だけコネクションが必要になる
初学者やAWS詳しくない人が、最適な使い方を学ぶのには良い本でした
逆にある程度くわしい人は、知らないところをつまみ食いすればそれで終わる感じでした
勉強する必要が出たのでおぼえがき
「レピュテーション（reputation）」とは、電子メールの送信元の信頼性や評判を示す指標
スパムや悪質なメールを送信する、IPアドレスやドメインを共有しているリスト
ここに入ったからといって、ただちにメールが受け入れられなくなる訳では無いが、レピュテーションの評価に強く影響を受ける
この辺が有名らしい
メールを受信したユーザが「迷惑メールを報告」などのボタンを押すこと
新規にメールサーバを立ち上げた場合、レピュテーションが低い状態でいきなり大量のメールを送信すると、スロットリングされることがある
そのため、少しづつメールを送って、レピュテーションを高めていく作業をIPウォームアップと呼ぶ
メールが配信できなかった。ということを指す用語
受信側からエラーコードが返ってくる
受信側の都合でメールが受信できない
など
なお、スロットリングはソフトバウンス扱い
受信側ではどうにもできない理由でメールが受信できない
など
レピュテーションが低下するため、ハードバウンスは避けなければならない
無効なメールアドレスにはメールを送らない
メールシステムを利用しているのであれば、ハードバウンスが帰ってきたメールアドレスは送信リストから削除して、受信側に迷惑をかけないようにする
👇4.2.3 数字順の返信コード に受信側のレスポンスコード一覧がある
スロットリングとは、システムの過負荷や特定利用者による資源の独占を回避するため、一定の制限値を超えた場合に意図的に性能を低下させたり、要求を一時的に拒否したりする制御のこと。
メールシステムにおいては、受信側が大量のメールの受信を制限する機能
sendgrid.kke.co.jp sendgrid.kke.co.jp
メールサービスに存在する、ハードバウンスや苦情等を受け取って送信対象外とするメールアドレスの一覧
Configuration set-level suppression というのがあるそれぞれ挙動は微妙に違う
キャリアメールだと「特定のドメイン以外受信しない」設定があるため、特定のドメイン外のメールを受けてハードバウンスを食らった場合に、 受信可能なドメインのメールもサプレッションリストのせいで送信できない 、という問題があるらしい
（ハード）バウンスはメールアドレスが存在しないなど、恒久的なエラーの場合に発生するものなので、一度バウンスすると他のユーザからも送信不可能にするSESの仕組みは非常に合理的といえます。ただし、日本で使用する場合に問題になるのが携帯キャリアへ送信する場合です。
例えば、ドメイン指定拒否をしている人に対して、許可されたドメイン以外から送信すると、バウンスが発生します（挙動はキャリアによって異なります）。そうすると当然Suppression Listに掲載されてしまうので、許可されたドメインから送信していた人もSuppression Listに引っかかってしまい、送信ができなくなってしまいます。リストから削除しても、また他のドメインから送信されてしまうと、また巻添いを食らってしまいます。これがSESが携帯キャリアへの配信と相性が悪いと言われる所以だと考えています。
instances の中で promotion_tier を設定すれば良い
instances = {
1 = {
# 未指定だと 0
instance_class = "db.r5.2xlarge"
publicly_accessible = true
}
2 = {
identifier = "static-member-1"
instance_class = "db.r5.2xlarge"
promotion_tier = 10
}
3 = {
identifier = "excluded-member-1"
instance_class = "db.r5.large"
promotion_tier = 15
}
}
READER のカスタムエンドポイント内のリーダーインスタンスが昇格するとどうなるの?フェイルオーバーや昇格に伴って DB インスタンスのロールがライターとリーダーの間で変更されると、Aurora は静的リストまたは除外リストで指定された DB インスタンスを変更します。
例えば、タイプ READER のカスタムエンドポイントに Aurora レプリカが含まれ、その後、ライターインスタンスに昇格されたとします。新しいライターインスタンスは、カスタムエンドポイントの一部ではなくなります。
👆ここの「カスタムエンドポイントのメンバーシップルール」より
GitHubのRSA SSH 秘密鍵が漏洩したため、2023/03/24 にGitHubのRSA SSH ホスト鍵が変更されました
known_hosts に格納するknown_hosts に鍵が格納されると、次回以降のSSH接続では、known_hosts にある公開鍵と、サーバから受け取る公開鍵に差異が無いことを確認して、サーバが偽物に成り代わっていないかチェックするようになるホスト鍵(公開鍵も)が変わり、known_hosts にある GitHub の公開鍵と、GitHub受け取る公開鍵に差異が発生するため、SSH接続が失敗するようになる
具体的にはこんなエラーが出る
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is d5:2c:63:d9:bc:75:9d:de:b1:4e:36:28:9f:7a:9c:39. Please contact your system administrator. Add correct host key in /home/hoge/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/hoge/.ssh/known_hosts:3 RSA host key for github.com has changed and you have requested strict checking. Host key verification failed.
👆/home/hoge/.ssh/known_hosts の3行目にある公開鍵と、サーバから受け取った公開鍵が違うよというエラーメッセージ
公式ドキュメントの手順に従えばOK
known_hosts から古い公開鍵を削除
ssh-keygen -f /home/hoge/.ssh/known_hosts -R github.com
👆github.com に関する known_hosts の情報を削除するよというコマンド
known_hosts に手動で以下の公開鍵を追加
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
実際に GitHub に SSH して動作確認する
$ ssh -T git@github.com Warning: Permanently added the RSA host key for IP address '20.27.177.113' to the list of known hosts. Hi hoge! You've successfully authenticated, but GitHub does not provide shell access.
警告が出なければOK
ウチのサーバの場合、さらに以下の警告も出たので同様に公開鍵を削除した
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '20.27.177.113'
ssh-keygen -R 20.27.177.113
SSH公開鍵については、過去のblog記事で解説してます
pg_dump -d ${dbname} > /var/tmp/dbname.dump
pg_dump -d ${dbname} -t ${tablename} > /var/tmp/dbname.dump
pg_dump -d ${dbname} -T ${tablename} > /var/tmp/dbname.dump
pg_restore -d ${dbname} --jobs8 /var/tmp/dbname.dump
jobs オプションは、indexの作成などを複数ジョブで実行するためのコマンド。CPUの数以内にする上記の場合、dumpファイルにDBの削除/生成の命令は入らないので、リストア前に手動でDBを削除/生成する必要がある
COPY (SELECT * FROM ${table_name} WHERE id > 123456789) TO '/var/tmp/tablename.dump';
COPY (SELECT * FROM ${table_name} WHERE id > 123456789) FROM '/var/tmp/tablename.dump';
pg_dump -d idoudb --no-acl -t ${table_name} -s > /var/tmp/table_name_schema.sql
Auroraにはファイルを置けないので、標準入力を使う
cat /var/tmp/tablename.dump | psql -c "COPY tablename FROM STDIN"
