読者です 読者をやめる 読者になる 読者になる

kariaの日記 @ Alice::Diary

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

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

最近あまりにも更新しなさすぎなので最近の画像をもりもり貼ってごまかす

IMG_20160313_222756

初めて「取り戻した」のが3月6日という、遅れてきたガルパンおじさんです。こんばんは。

最近あまりにも近況書いてなさ過ぎということで、Flickrの画像でも貼りながら振り返ろうというこの企画です。完全に生存報告というか自己満足ですがご容赦ください。

IMG_20160306_162915

爆音帰りに立川駅で足下を見たらこのカオスっぷり。わかるけど、いやわかるけど、もうちょっとなんとかならなかったん。

IMG_20160406_212218

最近はすっかりガルパン二次創作RTおじさんと化していますが、ちゃんとキンプリ応援上映にも行きました。大事なのは格。

DSC_0381

そいえば4月は、初めて竹原のたまゆらイベント行ったのでした。本物の高校でやるイベントに参加するの初めてだし、何しろ卒業式だし、それで中島愛坂本真綾サプライズで呼ばれたら泣いてしまうやろ。

DSC_0391

帰りに500系新幹線にも初めて乗りました。福山に最終のぞみ止まらないので致し方なく。

DSC_0348

時間が前後しますがRed Wingにも初乗車しました。広島は大都会。

DSC_0345

さらに遡ると春秋航空も初でした。だって広島に行くLCCこれしかないし。

IMG_20160128_213121

めちゃ遡って、全然関係無いんですが会社最寄りのテルルが閉店してしまいました。昔ここでIS12T(東芝製WindowsPhone)買ったんだよなー。懐かしい。

IMG_20160115_211948

そういや年始付近ではワグナリア復活とかもあったな。行く度にプレートとパフェとサイダー頼んでコースターガチャ3枚引くというハイカロリー生活を2週間ほどの間にこなさくてはなりません。今回はさすがに追いパフェすることはありませんでした(引きがよかった)。

P_20160224_223043

ここから脈略が特にない画像集。ちょっとずるすぎるアマゾン箱。

P_20160521_145005

風景写真です。コメントは差し控えます。

IMG_20160101_232034

プレモルめっちゃ買ってシールを集めると全員もらえるご家庭用ビールサーバーをゲットしたんですが、プレモルを飲みすぎたせいで発泡酒とか飲めない体になってしまい見事にハメられた感があります。おさけおいしい。

P_20160524_235324_1_p

これ駅に貼ってある業務用の終電接続表なんだけど、なんで「NAVITIME」の部分を中途半端に頑張って再現しようとしたのかすごい気になる。

IMG_20160327_145058

今期アニメで最高(というか現状最新話まで追いついている唯一のアニメ)が三者三葉なんですが、Anime Japanの時点でブース写真を撮るぐらいには注目してたらしい。そりゃまんがタイムきらら連載陣で現役最古参の連載がアニメ化すると言われたらそりゃあね。あとみでしみんですし。

P_20160101_180700

そうだ、今年は元旦からRhodanthe*のライブがあったのでした。Anime Japanで新作制作決定の発表があったの、非常にめでたいですね。

FIRST*MODE [Blu-ray]

FIRST*MODE [Blu-ray]

キリがないのでこの辺でおしまい。

slackのreminderの日時指定がわかりにくかったのでメモ

みんな大好きチャットツールのslackですが、reminder機能の日時指定の方法がわかりにくくて試行錯誤してしまったのでメモっておく。

サンプル

/remind #channel_name on 02/10/2016 at 10:00am to メッセージ本文

説明

  • on:日付を設定
  • at:時間を設定
  • to:メッセージ本文

試行錯誤したところ

onの日付の設定がなかなかうまくいきませんでした。

何故か?

YYYY/MM/DD (年/月/日) の順序で書いていましたが、この年月日の順序こそが誤りでslackに無視され続けていました。

実際には MM/DD/YYYY (月/日/年) の記法で書くのが正解。日本人にはなじみが薄い書き方なので、ヘルプを見るまで気付きませんでしたよ……。

ヘルプ(公式):

get.slack.help

余談

ちなみにon,at,toの順序性は特にないですが、書き方によっては誤った記法で指定した on の日付がメッセージ本文の一部として認識されてしまったりするので注意が必要です。柔軟すぎるのも中々考え物だなぁ。

My Space

My Space

誕生日なのでMySQLの話をする(その2)

この記事は、animateLAB Advent Calendar 2015 13日目の記事です。

こんばんは、kariaです。きょうは昨日の「誕生日なのでMySQLの話をする(その1)」の続きを書こうと思います。

これまでのあらすじ

MySQLのデータ(本番環境)を過去のダンプファイルで上書きされちゃった!?どーしよ!?

復旧までの道のり

我々の手元に残されたデータは以下の2つです。

  • 早朝のデータ移行時に使用したダンプファイル
  • MySQLのデータディレクトリ一式(←夕方に上書きされちゃったやつ)

上書きされちゃったやつはもはやどうしようもないし、早朝時点のダンプファイルを使って再構築し直してその日中帯のトランザクションは諦めるか、という案もありました。とはいえ、「諦めって言われてもその間のトランザクションは具体的にどうするんだ、ログから全部洗うか?」という事になりますし、「無くなりました、ゴメンナサイ」ということにはしたくないものです。

ここでMySQLのとあるオプションを思い出してみましょう。

log_bin         = /var/lib/mysql/mysql-bin.log
expire_logs_days        = 0

これはバイナリログの保存先ディレクトリと、どれぐらいの期間でexpire(削除)するかというオプションです。バイナリログは通常MySQLレプリケーションを実現するために使用されます(マスターDBが差分をバイナリログファイルとして出力して、スレーブDBが取り込んで反映する)。MySQLのデータディレクトリが肥大化するのを防ぐため、バイナリログをexpireされるまでの日数を小さく制限するというTIPSをよく見かけます。

が、MySQL リファレンスマニュアルにあるバイナリログの項目を読むと以下のように記載されています。

バイナリロギングを有効にしてサーバーを実行すると、パフォーマンスがいくらか低下します。ただし、レプリケーションをセットアップでき、リストア操作に対応できるというバイナリログの利点は、一般的にこのパフォーマンスの減少よりも重要です。

そう、バイナリログはリストア操作のためのバックアップとしても機能します。ということは

早朝のデータ移行時に使用したダンプファイル + 早朝~夕方(サイト閉鎖直前)までのbinlog ⇒ サイト閉鎖直前までの完全なデータが帰ってくる!!!

やったー!!ということで夜を徹しての復旧作業が始まりました。

具体的な復旧手順

バイナリログからのリカバリですが、具体的には、mysqlbinlogというユーティリティーを使用します。使用方法は以下の通り。

# mysqlbinlog (binlog_filename)

※手元の環境で試したところ、一般ユーザで実行するとPermission deniedと言われてしまったのでroot権限で実行しています。

すると、以下のようにトランザクションの中身が平文で表示されます。

# at 684657
#151213 23:25:52 server id 1  end_log_pos 684657 CRC32 0x3e4f5587       Intvar
SET INSERT_ID=1268556/*!*/;
#151213 23:25:52 server id 1  end_log_pos 684989 CRC32 0x25bc1ac9       Query   thread_id=36    exec_time=0     error_code=0
SET TIMESTAMP=1450016752/*!*/;
insert into log (is_notice,nick_id,channel_id,log,created_on,updated_on) values ('0','42','1','うんっ!行くよっ!いつも、今が、最高でしょ!れでぃーごー! 14(aije) (from Alice Cartelet)',now(),now())
/*!*/;

平文で表示されますので、そのままパイプでmysqlコマンドに食わせても良いですし、ファイルに出力したりgrepしたりしても構いません。なお上記サンプルは、tiarraMetroに付属するLog::DBIというtiarraのmoduleを利用して、私がTwitterに以下のような発言をした際に発行されたinsert文です。

このコマンドがあれば実質的にMySQLへ発行された更新系のクエリを全て追うことができ、非常に便利なコマンドですので覚えておきましょう。

さて、これを踏まえて具体的な復旧手順は以下のようになります。

  1. 早朝時点のデータダンプを改めてインポートする
  2. mysqlbinlogユーリティティを使用して早朝時点~夕方(サイト閉鎖時点)までのトランザクションをバイナリログから取りだす
  3. インポートしたdatabaseに上記トランザクションを適用する

かんたん3ステップ!というように見えますがそうはいきません。

2ステップ目で「早朝時点~夕方(サイト閉鎖時点)までのトランザクションをバイナリログから取りだし」と書いてますが、MySQLのバイナリログはmysql-bin.000001といったように無機質な連番でファイルが作成されていくので、一見してどこからどこまでが適用対象のトランザクションなのかがわかりません。ただ、一定のファイルサイズを超えると次の番号のファイルへ出力されるようになるのと、上記で示したようにトランザクション実行日時がコメントアウトされた形で示されていますので、ファイルのタイムスタンプとトランザクション実行日時を手がかりに当該のトランザクションを全て洗い出します。これ自体は手作業(目視)で行うことになりました。

これらの作業をたまたま空いていた別環境を用意して検証し、トランザクション適用で1件もエラーが出ないこと・夕方時点までのトランザクションが実際に入っていることを確認した上で、本番環境で実施・およびアプリケーションの動作確認・メンテナンスモード解除といった流れとなりました。また、これら作業の中で「default charset=utf8つけた???」と親の敵のように何度も確認したことも忘れられない思い出です。

データ量にもよりますがこれらの作業にはそれなりの時間がかかります。確かトランザクションの適用中のことだったと思うのですが、日付が変わったあとどこかで「昨日誕生日だったんですよね……」と漏らしたところ、当時の上司がケーキを買ってきてくれるという出来事がありました。バイナリログから復旧させるというアイデア自体も私ではなく別の上司のアイデアですし、1人できる復旧作業ではありませんでしたので当時の同僚や上司には本当に感謝しています。

ということで、私の中で「誕生日といえばMySQL」という謎のワードが生まれたきっかけになった出来事をご紹介しました。mysqlbinlogコマンドは大変便利ですので是非活用しましょう。また、log_binオプションはデフォルトだと無効になっているので、レプリケーションを行わない環境であっても有効にしておくと良いでしょう。