シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
こんにちは、DBAです。 おもむろにDiskの使用量がぐいっと上がって、ぎゃーなんかバイナリーログが溜まってるー、なんてことがたまにあります。 何らかの要因でサービスが大人気を博し、「おおっとこれはいきなりシャーディングの機運でござるか？ドゥフフフｗｗｗ」なんてことならうれしい限りなんですが、 ∧＿∧ ﾊﾟｰﾝ （ ・∀・） はやくめをさませ！ ⊂彡☆))Д´) まずは調べてみないとわかりませんよね。 という訳でどこが書き込みまくられているのかを調べる必要があったり、仮に本当のユーザートラフィックでドゥフフフ状態だったとしても、User Generated Contentsだとそれは特定のユーザーに依存するものだったりして裏だけは取っておきたかったりするわけです。 ということで都内のDBA 1.000人御用達のスクリプトを紹介します。 my_script/mysqlbinlog_liste
前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。 調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。 binlogローテート時の障害 数十分に１回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1～3秒は更新機能が停止するので、結構なレベルの障害ということでした。 binlogは1GBでローテートするように設定していたのですが、dstat -d でwrite容量を見ていると、確かに切り替わり時に800～900MBの書き込みを確認できました。 このことから、bi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
