kariaの日記 @ Alice::Diary

ノリツッコミの鳩子がはてなブログ書いちゃうよ

kariaの日記です。本家サイトはside=2です。Twitter ID:@karia
過去記事へのリンクとかは最下部参照。

Mackerelの外形監視でメッセージにEOFと出たときはクライアントからの接続に失敗したとき

今回もまたタイトルオンリーの記事。

MackerelのHTTP外形監視で、メッセージに「EOF」とだけ表示されるアラートが発生することがあります。こういうの。

f:id:karia:20190514111058p:plain
EOF

これはMackerel側からの接続がうまくいっていない(connection failedな)ときに発生します。クライアント起因ではなく、例えば「Mackerel向けのセキュリティグループだけ設定が間違ってました」とかそういうサーバー側の起因によるものなので、ポートとかソースIPの許可を見直してみましょう。

この問題、過去2回もハマってしまったのでメモっておく。今回も「EOFってなんじゃい、レスポンスの中身おかしくなってるのか?」となって特定に時間がかかった。なんでEOFというメッセージになるのかは、問い合わせした気がするけど忘れてしまった(もうちょっとわかりやすいメッセージだと有り難いみたいな要望はしたと思う)。

Mackerel サーバ監視[実践]入門

Mackerel サーバ監視[実践]入門

Aurora MySQLでバイナリログを有効にするときは再起動がいる(けど逆は不要)

タイトルが全てなんですが、Aurora MySQLでバイナリログが無効になっていてやっぱり有効化したい(バイナリログ出したい)というときは再起動がいる。逆は不要。

バイナリログが無効なとき

show binary logsしようとすると「お前バイナリログ使ってないぞ」って怒られる。

mysql> show binary logs;                                                                                                                                                                                          
ERROR 1381 (HY000): You are not using binary logging                                                                                                                                                              

log_binパラメーターもOFFになっている(このパラメーターは変更することができない)。

mysql> show global variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
1 row in set (0.04 sec)

binlog_formatはなぜかROWになっている(DB クラスターのパラメータグループでOFFに設定しているので謎な挙動)。

mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.02 sec)

有効化する

DB クラスターのパラメータグループでbinlog_formatをOFF→ROWなどに変更し、再起動する

このbinlog_formatパラメーターを変更すれば良いということは様々なブログなどに書かれているが、公式ドキュメントの以下のページが一番正確だった。

Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション - Amazon Aurora

binlog_format パラメータを OFF から別の値に変更した場合、変更を有効にするために Aurora DB クラスターを再起動する必要があります。

と記載されており、このケースでは変更するだけではダメで再起動が必要。binlog_formatはdynamicなパラメーターなので再起動不要だよね、と早とちりしてるとハマります。

なおAWS推奨はROWではなくMIXED。

バイナリログが有効なとき

再起動するとshow binary logsしたときの挙動が変わり、ログファイルの一覧が出る。

mysql> show binary logs;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000851 |      1003 |
| mysql-bin-changelog.000852 |       150 |
+----------------------------+-----------+

log_binはONになっている(変更できないパラメーターなので、Auroraが勝手に変更している)。

mysql> show global variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+

binlog_formatはDB クラスターのパラメータグループで設定した通りROWになっている(OFFにしてるときも一緒だったけど)。

mysql> show global variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

ちなみに読み取り専用ノードでは再起動してもバイナリログは出力されないようです(ドキュメント捜索中)。マスターノードでやりましょう。

以上!

ImageFlux Meetup #3で話した

3月中旬にImageFlux Meetup #3というイベントでお話してきました。もう20日ぐらい?経ってるけど一応書き留めておく。

f:id:karia:20190405005415p:plain

DMM.make AKIBA、初めて行ったよ。名前は知っているけど行ったことがない場所ベスト10のうちの1つ。

資料

スライドはこちら。

speakerdeckに上げてから「表紙もっと工夫すればよかった」って思った。サムネ大事。

発表内容の話

「何話そうかな」とネタを考えたときに、やっぱりイベントに来る人って導入の話を聞きたいのかな?って思って導入の話にしました。「なんで導入したの?」とか、そういう背景というかコンテキストが知りたい人が多いのかなーと。

先にタイトルを決めてから内容を書いたのですが、タイトルの別案として「ImageFlux導入時のハマりどころ ~私たちは画像形式のことに無知だった~」というのもありました(Evernote見返したらそう書いてあった)。

結局のところImageFluxに限らないと思うけど画像変換がらみのサービスを導入するときにハマるところって、画像形式に無知なことが遠因としてあって(自分のことです)、そういうところがノウハウとして欲しいんじゃなかろうかと思ったので思いついたタイトル案だったのですが、煽りすぎな感じがするのと発表内容が迷走して時間オーバーしそうだなーという気持ちもあり、無難なタイトルに落ちつきました。どこかで供養してもいいかもね。

参加された皆様&運営の皆様、どうもありがとうございました!