重い腰を上げてようやくMovableType7に上げました。

ついでにOSも最新まで上げたくて、そこから新規で作ったので、かなり手こずりました。
OSをバージョンアップしたことでMySQLも5.7から8に上がったのですが、データがフルバックアップからインポートできず、結局データベース単位でバックアップし直してインポートしたり、Apabheのパッケージで追加するものがわからなかったり。

Ubuntu 18.04LTSでDRBD9の分散ストレージを作るメモです。

DRBD（Distributed Replicated Block Device）とは、Linux上でネットワークを介したストレージをリアルタイムにミラーリングするためのソフトウェアです。
何が出来るかと言えば、2台〜4台のコンピュータ間のストレージで完全に同期を取ることが出来ます。
Active/Standbyで動作しているActive側でストレージに書き込みが行われると、ネットワークを介してSlave側のストレージにも書き込みが行われることで、データが同期されるという仕組みです。
また、同期はブロック単位でおこなわれるので、スライス（パーティション）がそっくり同期されます。その為、ファイルシステムに依存しない事も特徴です。（ファイル単位での同期ならrsync使うとか、他にも方法は色々あるけれど）

通常クラスタ構成のシステムでは共有ストレージなど「高価なハードウェア」を使うか、レプリケーションソフトで定期的に同期を行う方式が一般的だと思います。レプリケーションソフトの同期では同期のタイミングによって時間差が生まれてしまうため、同期が取れていないタイミングが発生しますが、DRBDではブロック単位の書き込みをそのままネットワークを介して行いますのでほぼリアルタイムの同期が行えます。
（市販のクラスタソフトウェアでも似たような仕組みを備えている製品があるようだ・・・）

Linuxではクラスタ自体はPacemaker（旧 Heartbeat）で行えますので、複数のコントローラ、複数のパスを備えた高価なストレージを使わずにクラスタのシステムが作れる事になります。とはいえネットワークを介して同期するってことは、ネットワークに相当負荷が掛かるということですので、高パフォーマンスを要求されると厳しい気がします。
仕組み自体は昔からあった（カーネル2.6の頃･･･2009年位？･･･に生まれたらしい）のですが、これまで触ってこなかったので、今更ながらちょっと触ってみましょうという感じです。

先日自宅サーバの障害復旧で面倒な目に遭ってしまったので、色々と見直し。。。

まずサーバのバックアップ

反省。定期的に取りましょう(^^;　少なくともバージョンアップ前には・・・

• ディザスタリカバリ：無し→Acronisでイメージバックアップ（外付けHDDにバックアップ）

LVMだったのでスナップショットに頼り切っていて、バックアップを怠っていたので

• ファイルシステム：LVM→Ext3

Acronisでイメージバックアップが取れるようにExt3を使用することに

• スナップショット：LVMスナップショット→cronとdumpとtarで地味にバックアップ

ということで、スナップショットは便利だけど捨てて、地味に昔ながらのファイルバックアップを行う事に。

Acronis True Image Home （面倒臭くて2009しかインストールしてなかったのだけど、Home2010のライセンスは買ってあったので）なんて久しぶりに使ったのだけど、簡単にUSBブート出来るようになってたりしていて、地味に便利になっている。

あと、スナップショットは便利だけど、スクリプト組んでファイルバックアップを行う方法は昔ながらのノウハウで色々出来て楽っちゃ楽。

バックアップだけをみると、MacOSXのTime MachineはGUIで簡単にスナップショットから好きなファイルだけ抜いてこれる上、ディザスタリカバリにも対応できる点が良いかな。Windows7の標準バックアップも賢いようだけどまだ使ってみてない。地味にWindows2008のServer BackupはディザスタリカバリにDVDからの復旧が使えるようになってたり良くなってる。何にせよ問題になるのがデータベースのバックアップ。スナップショットだろうとファイルでバックアップを行う方法だろうと、データベースの不整合から逃れる術は無くて、結局データベースの停止を行ってダンプしてファイルにバックアップするか、オープン中のファイルをバックアップできるソリューションを使う必要が有るのだけど。


データベース（MySQL）のバックアップ

結局完全なバックアップは難しいのでファイルへのダンプと、データベースのクラスタを併用することに。

• ファイルへのダンプ

mysqldumpでフルダンプ。テキストファイルに吐き出しておく。

/usr/bin/mysqldump -x -A -u データベースのユーザ --password='パスワード' --opt > /var/db-backup/DB-dump.`/bin/date +'%Y%M%d%k%M'`
gzip /var/db-backup/DB-dump.`/bin/date +'%Y%M%d%k%M'`

とか、そんな感じのシェルスクリプトを作ってcronで定時実行する。

• MySQLのレプリケート

まずマスターサーバ側でネットワークソケットを空けたり、bin-log取ったりと、クラスタ化の準備。

/etc/mysql/my.cnfに
[server]
server-id        = 1
log-bin
を追記。

データベースに設定を反映させるために再起動する
(Slave)# sudo service mysql restart

レプリケート用にREPLICATION SLAVE権限を与えたユーザを作っておく。

mysql(Master)> GRANT REPLICATION SLAVE ON *.* TO repl@10.0.0.2 IDENTIFIED BY 'password';

データベースの更新をストップして

mysql(Master)> FLUSH TABLES WITH READ LOCK;

バイナリログを確認（スレーブで同期させるときに必要な情報）

mysql(Master)> SHOW MASTER STATUS;
+-----------------+----------+--------------+------------------+
| File            | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------+----------+--------------+------------------+
| dbsv-bin.000001 |       79 |              |                  |
+-----------------+----------+--------------+------------------+
1 row in set (0.00 sec)

スレーブ側にコピーする為にデータベースのダンプを取る
(Master)# tar zcf backupfile.tar.gz /var/lib/mysql/
（取ったファイルはスレーブ機にコピーする）

ファイルが取れたのでデータベースの更新を許可

mysql(Master)> UNLOCK TABLES;

別のホストでスレーブサーバを立てて、レプリケートを行う。

データベースを停止して
(Slave)# sudo service mysql stop

スレーブの設定を記述する
/etc/mysql/my.cnfに
[server]
server-id        = 2
を追記。

データベースに設定を反映させるために再起動する
(Slave)# sudo service mysql restart

マスターで採取したファイルを解凍＆展開
(Slave)# cd /
(Slave)# tar zxf backupfile.tar.gz

データベースを動作させて
(Slave)# sudo service mysql start

マスターとの同期情報を設定して

mysql(Slave)> CHANGE MASTER TO
MASTER_HOST='10.0.0.1',  ← マスターのホスト名/IPアドレス
MASTER_USER='repl',      ← マスター接続に使用するユーザー名
MASTER_PASSWORD='password', ← パスワード
MASTER_LOG_FILE='dbsv-bin.000001', ← さっきマスターで確認したファイル
MASTER_LOG_POS=79;       ← さっきマスターで確認した位置

同期を開始させる
mysql(Slave)> START SLAVE;

こんな感じでMySQLのファイルダンプと、MySQLのレプリケーションを設定した。
レプリケーションは冗長目的なので、あくまで受け身の同期でしかない。selectとかの検索系のクエリは使えるけど、insertとかupdateとかの更新系のクエリは使えない（というかマスターに反映しない）。けど、必要が有ればスレーブ側のデータベースを停止させればデータベースのフルバックアップが取れるし、スレーブ側のデータベースを再開させれば、またマスターとの同期が行われる。
検索系のクエリを分散させれば、一応データベースの負荷分散にもなるのだけど、そもそも負荷の問題は無いし、目的が違うので気にしない。
MySQLのレプリケーションについては公式サイトにある情報（http://dev.mysql.com/doc/refman/5.1/ja/replication.html）で必要な情報は揃えられる。SQL ServerであればMSDN(http://msdn.microsoft.com/ja-jp/library/ms187048.aspx)か？

という事で、やっとデータのバックアップとかするようになりました。

ActivePerlからMySQLを使いたかったんですが・・・以前Linux/UNIX環境ではDBIとDBD::MySQL使ってやったのですが、今回は別の方法を採ることにしました。ActivePerl用のDBD::MySQLのPPMパッケージも存在するのですが、今回は既存の環境があってその上で動かさなきゃならないという制約もあったし、インターネットへの接続も出来ない。その上、インストール作業自体も出来るだけ簡単に行えるようにする必要があったので、Windowsへインストールするものはインストーラが用意されているものを中心に選ぶことにしました。幸いMySQLのODBCコネクタならmsi形式のインストーラも準備されているし、ActivePerlの配布パッケージにもWin32::ODBCが含まれているので、ODBCコネクタ、MySQLとActivePerlをGUIからインストールするだけで環境を整える事が出来そうです。そんな訳でMySQLのODBCコネクタをインストールして、PerlからWin32::ODBC経由でMySQLを使うことにしました。使いかた自体にさほど差はないのですが、データベースとの接続部分はODBC側の設定になるのでPerl上で設定すべき項目が少ないのは便利かも知れません。

クライアントからバラバラと飛んでくるデータの集計を行うような仕組みが必要になっているのですが、なかなか無いんですね。フリーでそれっぽいものがあれば良いのですが、非常に簡素なWebシステムを作る必要がありそうな・・・。極々小規模かつ簡単なもので十分なんですが。

自分でも何屋さんなのかさっぱり分からないんですが。システム屋さんとか、言語屋さんじゃないことは確かです。そのはずなのに定期的にゴリゴリとフルスクラッチで書くような仕事が出てきてですね、確か一昨昨年くらいはJava使ってたし、一昨年はCで、去年がVBSとPerl。今年はPHP、Perl、VBSとMySQLかPostgreSQLの組み合わせになりそう。（あくまでフリーで揃えられることが前提なので）

本職の人なら、ささっと作れちゃうんでしょうけど。いつも通り、かなり苦労しそうな悪寒が・・・。