master と staging ブランチ以外は強制的に消えるので注意してネ。 \| でつなぐと、除外するブランチ増やせるから、適時試してみて下さい。
git branch | grep -v "master\|staging" | xargs git branch -D
ちなみに、ググるとおマージ済みブランチだけ消す、みたいなのも見つかるから適時調べて下さい。
delayed_job の動作ログを Rails ログファイル以外に出力する
production.log に大量の UPDATE クエリが記録されてログファイル汚染で「ウッ！」となるやつを回避する。
VirtualBox アップグレードしたら vagrant up でエラーでた
でた。 bash: line の行数は、人によって前後するはず。
bash: line 4: setup: command not found ==> default: Checking for guest additions in VM... The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! setup Stdout from the command: Stderr from the command: bash: line 4: setup: command not found続きを読む
マイナーバージョン自動アップグレードの「設定変更」
全環境の RDS インスタンスで運用している MySQL に マイナーバージョン自動アップグレード を入れていた気がして、確認した記録です。 （ちなみにこれを書いている現在、発熱で38度を超えており、本番が突如落ちる謎の悪夢を見て起きたゆえです……ううっ）
RDS のバージョンアップ時のダウンタイム
これは AWS 公式にも書いてあるとおり、 MultiAZ だろうとリードレプリカだろうとダウンタイムの発生から逃げることができません。
では、 ManagementConsole の RDS 管理画面から、該当インスタンスの設定を変更する マイナーバージョン自動アップグレード のチェックを外し適用した場合のダウンタイムはどうでしょう。
結論から言えば、 （ RDS でダウンタイムが発生する）他の変更に関するキューがなければ、このチェックを外すだけでは、ダウンタイムは発生しません。
チェックを入れていてしまっている君、いますぐ外そう！ メンテンナンスウィンドウの時間が、運用しているサービスのメンテナンス時間に設定されている場合は外さなくていいぞ！ サービス設計のうまい人がいてよかったな！
すぐに適用
すぐに適用を選ぶと、メンテナンスウィンドウでマイナーアップデートが既にキューイングされていた場合、多分アップデートが走りきってから自動アップグレード OFF が適用されるはずです。
AWS の説明を信じるなら、事前に計画された RDS インスタンスへの変更キューがセットされている場合は、それらを消化してから実行、という解釈ができます。 けど今何のキューがセットされてるかってどこから確認すんのかなあ。
mysql_secure_installation: [ERROR] unknown variable 'default-character-set=utf8mb4'.
なして？ と思ったけど、インストール後プロセス起動前に以下を入れてたのが問題だった。 mysql_secure_installation は latin1 以外許さないとかそういうアレなの？ キマリなのかしら。
/etc/my.cnf
[client] default-character-set=utf8mb
