商用環境が Cisco 機器にリプレースされたので VPN クライアントも macOS 版あるじゃろ、とクライアント配布してくれ連絡したら、インフラ管理のベンダから「Windows 以外わかんないからやだ!」と想像を絶する返事が帰ってきて、新年早々から絶句しています。
Windows8.1 で環境作っちゃったけど、 Windows10pro のライセンス買ってくれって連絡しないとだめだなこれ。
続きを読むmaster
と staging
ブランチ以外は強制的に消えるので注意してネ。 \|
でつなぐと、除外するブランチ増やせるから、適時試してみて下さい。
git branch | grep -v "master\|staging" | xargs git branch -D
ちなみに、ググるとおマージ済みブランチだけ消す、みたいなのも見つかるから適時調べて下さい。
production.log
に大量の UPDATE
クエリが記録されてログファイル汚染で「ウッ!」となるやつを回避する。
でた。 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度を超えており、本番が突如落ちる謎の悪夢を見て起きたゆえです……ううっ)
これは AWS 公式にも書いてあるとおり、 MultiAZ だろうとリードレプリカだろうとダウンタイムの発生から逃げることができません。
では、 ManagementConsole の RDS 管理画面から、該当インスタンスの設定を変更する マイナーバージョン自動アップグレード のチェックを外し適用した場合のダウンタイムはどうでしょう。
結論から言えば、 ( RDS でダウンタイムが発生する)他の変更に関するキューがなければ、このチェックを外すだけでは、ダウンタイムは発生しません。
チェックを入れていてしまっている君、いますぐ外そう! メンテンナンスウィンドウの時間が、運用しているサービスのメンテナンス時間に設定されている場合は外さなくていいぞ! サービス設計のうまい人がいてよかったな!
すぐに適用を選ぶと、メンテナンスウィンドウでマイナーアップデートが既にキューイングされていた場合、多分アップデートが走りきってから自動アップグレード OFF が適用されるはずです。
AWS の説明を信じるなら、事前に計画された RDS インスタンスへの変更キューがセットされている場合は、それらを消化してから実行、という解釈ができます。 けど今何のキューがセットされてるかってどこから確認すんのかなあ。
なして? と思ったけど、インストール後プロセス起動前に以下を入れてたのが問題だった。 mysql_secure_installation
は latin1 以外許さないとかそういうアレなの? キマリなのかしら。
[client] default-character-set=utf8mb