MongoDBがダウンするようになったので、v2.4.5からv3.0にアップデートした話

参考になればシェアしてもらえるとうれしいです

  • このエントリーをはてなブックマークに追加
  • 8
mongodb

ある日、急にMongoDBが落ちるようになった。

ログを見る限り、「ロックファイルが残っているため立ちあげられない」という情報のみだった。

スポンサーリンク

目次

ダウン原因の調査

エラーログやMuninなどの監視ツールを調査した結果、ダウンした際の共通点があった。
それは

  1. メモリを2GB以上喰った際に落ちている
  2. MongoDBのロックファイルが残っている

ということだった。

一歩前進はしたが「メモリを2GB以上使うと落ちる」といった言語仕様や症例もなく、これだけでは原因特定が困難だった。

しかし、よくよく調べていくと同一サーバで動いているMySQLもおおよそ2GBのメモリを使用している。

そして、このサーバの物理メモリは4GBだ。

MongoDBがダウンする原因の仮説

  1. メモリリークが起こり、MongoDBがロックファイルを残したままダウンする
  2. 自動復帰するために再起動するが、ロックファイルがあるため立ち上がらない

というものである。

MongoDBダウンの回避対策

MongoDBのメモリ利用量を制限することで、メモリリークを起こさないようにしてみる。

しかし、残念ながらMongoDB v2系はメモリ制限の機能が存在せず、上記のような対策をとることが出来ない。

だが諦めるのはまだ早い。
Mongo v3から新規で追加されたストレージエンジン「Wired Tiger」にはメモリを制限する機能が備わっている。

これだ!

ということで、

  1. MongoDBをv2からv3にアップデートし
  2. さらにストレージエンジンを「mmap」から「Wired Tiger」に切り替え
  3. 「Wired Tiger」でメモリ制限をする

ことでMongoDBのダウンが再現しないか検証する。

ぶっちゃけ、AWSなどのクラウド環境や、DBサーバを並列で立てられたり移行出来る場合は移行して潤沢なメモリを割り当ててやるのが一番だと思いますw

MongoDBがインストールされているサーバ環境

環境はさくらのVPSです。

メモリ4GBのHDDプランだったと思いますので、下記の感じですかね。

  • OS: CentOS 6.5
  • メモリ:4GB

どこにでもあるCentOSのVPS機です。
では、これからMongoDBアップデートの旅に出かけましょう。

MongoDBのアップデートの前準備

CentOSのビットを確認

MongoDBには32bit版と64bit版があります。

32bit版は非推奨なので、OSが64bitであれば、可能な限り64bitをインストールしたいので、OSのbitを調べます。

上記が「x86_64」なら64bitです。

32bitだと「i686」などが返ってきます。

MongoDBをバックアップ

mongod.confの場所を調べ、mongodbのデータパスを明確にする。

dbpathを調べる

mongodbを停止

バックアップを取得

バックアップ先のディレクトリを作る

作成したディレクトリにバックアップのダンプを出力

MongoDBをアンインストール

バックアップの作成が完了したので、2.x系のMongoDBをアンインストールしましょう。

アンインストールはコマンド一発です。

無事アンインストールができたら、次にv3系のMongoDBをインストールしましょう。

公式サイトを参考にMongoDB v3.2をインストール

それではMongoDBをインストールしていきましょう。
インストールの手順は下記の公式マニュアルが非常に丁寧に説明してくれているので、見ながら順に実行していけば問題ないかと思います。

公式リポジトリを登録

YumでMongoDBをインストール

インストールもyumコマンド一発です。
簡単になりましたね。

これでインストールは完了です。
続いて設定に移っていきましょう。

MongoDBが起動出来るようにSELinuxを設定する

SELinuxに対し、MongoDBを許容するように設定します。
今回は問題となっているダウン症状が再現するかどうかのテストが目的であり、面倒だったので、SELinuxを無効化します。

必要に応じて、許容か無効化かを選択してください。

SELinuxの設定ファイルを作成する

作成したファイル内に下記を書き込む

無効になっているかを確認

「getenforce」コマンドでDisabledになれば無効になっています。

WiredTiger用の設定ファイルを記述する

MongoDBの新たなストレージエンジンである「WiredTiger」を利用するための設定を記述します。
設定はYAML形式で記述します。

設定ファイルを作成する。

ファイル名は何でもOKです。

設定を記述する

DBパスやその他設定は適宜変更してください。
今回、メモリを2GB以上利用して死んでいたので、サイズ制限を1GBに設定しました。

参考http://qiita.com/kuwa_tw/items/0a5704e9e505cffeae34

MongoDBの起動・リストア

アンインストール、インストール、設定ファイルの記述と終われば、いよいよ起動です。

起動の前に設定ファイルで定義したデータ保存ディレクトリがなければ作っておきましょう。

設定ファイルのパスを指定して起動する

毎回起動する際の設定がめんどうならば、

  1. 設定ファイルを「/etc/mongod.conf」に作成する
  2. 「/etc/init.d/mongod」の設定ファイルパスを書き換える

のどちらかでパス指定が不要になります。

バックアップしていたデータファイルをリストアする

無事起動したら、バックアップしていたデータをリストアしましょう。

これで起動は完了です。
大きなトラブルもなく、v2系からv3系に更新出来てよかったよかった。

そんなに世の中甘くない

バージョンアップにトラブルはつきもの。

うまく行ったと思っていたが、MongoDBのデータを読み書きするPHPスクリプトにアクセスしたら…

_人人人人人人_
> 突然の死 <
 ̄Y^Y^Y^Y^Y ̄

えっ。真っ白だよ。

PHPからMongoDBにつながらない。

そう。PHPからMongoDBにつながらないのである。
原因を確認したところ、なんと現行で動かしていたドライバ「mongo」にエラーが発生した。

PeclでインストールしたドライバがMongo v2.6までしか対応していなかったのだ。

仕方ないので、mongodb1.1をインストールすることに。

peclでインストールしたドライバがダメなら新しいやつインストールしてみよう。
そう思い、mongodb1.1をインストールしてみる。

開いたファイルの内容を

に変更。

よしよし。問題なくPHPドライバ「mongodb」がインストールされたので、再度確認。

_人人人人人人人人人人人人人人人人人人人人人人人人_
> Fatal Error – Class ‘MongoClient’ not found <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

よくよく中身をみると、そもそものコネクションクラスから、データのやり取りまで何から何まで変わってた。← あたりまえである。

つまり・・・当然プログラム全部書き換え!!

そんなのはお断りです。

…ということで

PHPドライバについて調べる

を参照。

mongo1.6ならmongodb v3.0に対応してるっぽい。

peclのmongoのバージョン確認

1.6だった。

ということで…。

再度DB側でv3.2をアンインストール→v3.0をインストール。

一度やった手続きなので慣れたもの。
サービスを停止し、MongoDBをアンインストールする。
やり方自体は公式ドキュメントに懇切丁寧に書いてあったので、それをなぞる。

v3.0をインストール


リポジトリを登録。
この時、以前登録した3.2のファイルは消しておきましょう。

yumでインストール実行。

設定ファイルを指定し、起動。バックアップからデータのリストアを実行。

元気に稼働し始めました。

よかったよかった。

番外編:Muninの監視から外れる

muninでメモリとか監視していたが、再インストール後監視から外れていたため、再登録を行う。
調べると、muninのmongodbプラグインはインストールされているが、稼働していない状態だった。

とりあえずMuninのプラグインを単体でテストしてみる。

エラーメッセージを読むと、RESTアクセス出来てないようだ。

調べたところ、セキュリティの関係上、MongoDBはデフォルトではRESTが無効になっているようだ。

設定ファイルに下記を加筆して、再度Mongoを起動

これでRESTを許可したので、Muninからもアクセスが行えるようになったはずである。

再度テスト

いけた。

munin-nodeの再起動

MuninのMongoDBのトラッキングも再設定できました。

あとがき

1ヶ月以上運用した結果、いまのところ以前のようなMondoDBダウンは1度も発生していません。
仮説の通り、単純にメモリ不足によるエラーだったものと思われます。

MongoDB自体アップグレードし、性能が上がり、メモリ利用量も少なくなっているので、結果オーライだと思います。

教訓: アップグレードは慎重に。でも大切なのでしっかりやろう。そして、事前の情報収集もしっかりと。

スポンサーリンク

参考になればシェアしてもらえるとうれしいです

  • このエントリーをはてなブックマークに追加

フォローする

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です