ARCHIVESDRIVE HB

オイラはホームベーカリー！

Rails のコネクションプール数

Rails

基本的に Rack サーバの Worker 数と同じにするべき。

qiita.com

Puma Web サーバー​を使用している場合は、pool​ 値を同等の ENV['RAILS_MAX_THREADS']​ に設定することをお勧めします。複数のプロセスを使用している場合は、各プロセスに独自のプールが含まれるため、ワーカープロセスが ENV['RAILS_MAX_THREADS']​ を超えない限りはこの設定で十分です。

devcenter.heroku.com

heroku くんもこう言っとる。 基本的に default に当たり障りない値を書いておき (これ今も初期化時に記述されるんでしたっけ)、リモート各種の ENV に個別に記述してあげようね。

default: &default
  adapter: mysql2
  encoding: utf8mb4
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default

staging:
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 2 } %>

test:
  <<: *default

production:
  <<: *default
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 6 } %>

RAILS_MAX_THREADS を設定する効果が、コネクションプール以外で発揮されるのかは、わからないです……。

それでもあふれるタイミングがある

インフラを見ている案件、稀にコネクションプール枯渇のお知らせが来る事が出てきて、今月は片手で数えられるくらいだった。 Thread も Worker も利用していないようなので問題ないと思うんだけどなあ、と思っていたけど、 Faraday で外部のサーバと通信しているかつ、この外部サーバがよく死ぬので、その箇所でなんかスタックして新規接続にコネクション配れないのか？ という気がしている。

コネクション is 難しい。

AmazonLinux2 に snapd を入れて certbot による証明書自動更新生活を満喫する

AWS Linux memo

前回 CentOS に snap を入れたら、謎のタイムアウトエラーで勝手にデーモンが死ぬ現象に遭遇。あまりに腹が立つので、別の環境で再試行してみることにしたらまた大変だったお話。

ざっと調べてみたら、メタ情報を編集させて認識させる？ など一年程度以上前の記事では、そのような記述がありましたが、現在はそこまでしなくても大丈夫なようになっていました。

続きを読む

prezto+powerlevel9k からユーザ・ホスト名を消す

memo

zsh に prezto と powerlevel9k を設定して使っていて、これらはとても便利。 なのですが、プロンプトに ユーザ@ホスト のように表示されており、作業証跡としてスクリーンショット取得したり、ターミナルの出力を利用すると写り込んだ情報がたまに邪魔といわれ困る。

ので、これを変更する。

どうする

環境によるけど、 ~/.zprezto/modules/prompt/functions/prompt_powerlevel9k_setup の L617 あたりの記述を変更すれば良い。

set_default POWERLEVEL9K_CONTEXT_TEMPLATE "%n@%m"
↓
set_default POWERLEVEL9K_CONTEXT_TEMPLATE "✖╹◡╹✖"

f:id:donbulinux:20210209235730p:plain
一体何ゆのっちなんだ……

できた。 固定文言を指定しているのが、シェルで色々変更できるので好きなように変更すると良い。

MySQL 8 でのバイナリログの無効化

MySQL

MySQL 8.0.x ではバイナリログが標準で有効化されている。 ので、無効化する。

[mysqld]
disable-log-bin

これでヨイ。

本当はローテートするようにして、ログを無効化しない方が良いのだけれど、開発環境だったり、定点バックアップ毎にしかデータ保証しない (保守コストの兼ね合い) 等の場合はこうしてやればヨイ。

anyenv 環境下で nodenv に乗り換える

node.js memo

現象は以下の記事と同じ、対処法もリンク先と同じです。 太古から anyenv 使ってる人以外は対応する必要ないやつですね。

qiita.com

環境変数 NODE_VERSIONS について

削除した ndenv のパスから以下に変更して動きました。 macOS 環境なので、他 OS 環境の方は適時読み替えるかディレクトリ掘って確認してください。

export NODE_VERSIONS=/Users/${ユーザ名}/.anyenv/envs/nodenv/versions

2021/02/17 追記

このままだと移行できてるけど global に指定した node が存在しないので .node-versions が存在しないプロジェクトで node コマンドエラーが出る。 いや .node-versions 作っとけよ、という話なのですが歴史的経緯とかで作れない場合もあるので、 nodenv global で LTS のバージョンでも指定しておくこと。

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

MySQL

なん……何？ (ここ数年 RDS ばかり使っていたので、生 MySQL を久しぶりに使った顔

ロケ地

  • CentOS7
  • MySQL 8.0.22 community edition
  • 該当ユーザの権限
    • GRANT ALL PRIVILEGES ${データベース名}.* ON ${ユーザ名}@localhost;

PROCESS 権限が足りない

mysqldump を実行したところ、表題のエラーが出た。 どうも PROCESS 権限が足りないらしいが、ダンプを取得したいデータベースに対して操作しているユーザは GRANT ALL している。 なん、なに？

dev.mysql.com

Incompatible Change: Access to the INFORMATION_SCHEMA.FILES table now requires the PROCESS privilege.

This change affects users of the mysqldump command, which accesses tablespace information in the FILES table, and thus now requires the PROCESS privilege as well. Users who do not need to dump tablespace information can work around this requirement by invoking mysqldump with the --no-tablespaces option. (Bug #30350829)

訳すとこう！

互換性のない変更：INFORMATION_SCHEMA.FILESテーブルへのアクセスには、PROCESS特権が必要になりました。

この変更は、FILESテーブルの表領域情報にアクセスするmysqldumpコマンドのユーザーに影響するため、PROCESS特権も必要になります。表領域情報をダンプする必要がないユーザーは、--no-tablespacesオプションを指定してmysqldumpを呼び出すことにより、この要件を回避できます。 （バグ＃30350829）

CREATE LOGFILE GROUP と CREATE TABLESPACE 用の情報を mysqldump に含めないオプションらしく。 明示的に CREATE LOGFILE GROUP などしていないので、アプリケーションの規模も小さいし除外してしまっていいかな、という感じで、権限付与せずロングオプションを利用することで回避することにしました。 こんなかんじ。

mysqldump -u ${ユーザ} -p -h localhost --no-tablespaces ${データベース名} > ~/db_dump/`date "+%Y%m%d%H%M%S"`-${PREFIX}.sql

dev.mysql.com

参考

isgs-lab.com