USBメモリ2本挿しでZFSミラーリング構成 にしてから一か月しか経ってないのに、もうエラーですか…今回はZFSのエラー訂正機能だかミラーリング相手だかを使ってデータロスはなかった模様。

ミラーリング構成にしてあるしFreeNASの設定は保管してあるので今回は様子見することにしましたが、どちらのメモリがエラーを出したのかは気になるので調べることに。

まずはどのデバイスがエラーを出したのか。ルートシェルから

[root@freenas ~]# zpool status -v freenas-boot
  pool: freenas-boot
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P 
  scan: scrub repaired 130K in 0h7m with 0 errors on Sat Aug  1 03:55:52 2015
config:

        NAME                                            STATE     READ WRITE CKSUM
        freenas-boot                                    ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            da1p2                                       ONLINE       0     0    27
            gptid/d7bb72a8-1b95-11e5-b672-000c29a6b2ea  ONLINE       0     0     0

errors: No known data errors

da1p2にチェックサムエラー(CKSUM)が発生しているので、怪しいのはda1らしい。次にこれが2本のうちどちらかを知るために

[root@freenas ~]# camcontrol devlist -v
(中略)
scbus7 on umass-sim0 bus 0:
<BUFFALO USB Flash Disk 1.00>:      at scbus7 target 0 lun 0 (pass4,da0)
scbus8 on umass-sim1 bus 1:
<UFD 2.0 Silicon-Power8G 1100>:     at scbus8 target 0 lun 0 (pass5,da1)

da1はSilicon powerの物らしい。

余談ですが、私はHDDでもUSBメモリでもRAIDを構成する時できるだけ違うメーカー・型番の物を混ぜることにしています。理由は二つ、

1. 同じメーカー・型番のドライブは似たような時期に壊れる可能性が高くなる(→RAIDデグレード中にもう一台逝ってしまう)
2. 交換するドライブが分かりやすい

RAIDの性能は一番遅いドライブに引っ張られる特性上、パフォーマンス重視の場合は同一メーカー・型番の方が良いのでしょうけど。

マイグレーションをリセット して元のデータをリストアする時、以下の条件に当てはまるエンティティがある場合注意が必要です。

• ナビゲーションプロパティを持っている(→テーブルに外部キーが設定されている)状態でプロパティを追加した(特にshort, integer, long integer等整数型)
• エンティティ定義しているソースコードの最後以外の行にプロパティを追加し、Add-Migrationした(ソースコード上のプロパティの順番が追加していった順になっていない)

問題はカラムの順番です。何が起こるかというと、プロパティ追加前、テーブルにはナビゲーションプロパティの外部キーを保存するためのカラムがあります。特にKey属性などを設定してない場合、参照先のIdカラムと同じinteger型になるでしょう。ここに新しいプロパティを追加すると、カラムの順番の最後に入ります。

Id	integer primary key
Name	varchar(30)
NavigationId	integer (参照先のKeyカラムの型)
NewPropterty	integer

次にマイグレーションを整理してテーブルを作り直すと、ナビゲーションプロパティのカラムが最後に入ります。

Id	integer primary key
Name	varchar(30)
NewPropterty	integer
NavigationId	integer (参照先のKeyカラムの型)

リストアは作り直した空テーブルへの実行となりますから、mysqldumpにはno-create-info(-t)オプションを付けることになると思います。これで出力されるファイルにはカラムの順番情報がありません。リストア先のテーブルもId, Name, NavigationId, NewPropertyの順番でカラムが並んでいる前提になってます。

このダンプファイルを使って作り直したテーブルにリストアするとNewPropertyとNavigationIdの値が入れ替わって保存されます。NewPropertyがvarcharなどNavigationIdと異なる型になっている場合はエラーなどになるでしょうが、同じ型の場合エラーなく保存されます。外部キー整合性のチェックはリストア時には行われないようです(やったらめちゃくちゃ重くなりそうだし)。結果ナビゲーションプロパティはでたらめなデータを参照します。

上記の内容がよく分からない、マイグレーションを重ねすぎて条件に合致するか分からない場合は、complete-insertオプションを付けてmysqldumpを実行した方が安全です。ダンプ・リストア共に劇的に遅くなりますが。

昔の記憶ですがPostgreSQL(8.1)もダンプはこういう仕様(オプション付けないとカラムの順番を保存しない)だったような。テーブル大きいとダンプ・リストアも高速化したいですからねぇ。

保険のためにデータベースのフルダンプ(テーブル作成SQL込み)を取ってなかったら爆死だったな…

Update-Databaseを実行すると、なぜか対象のDBがフレッシュだと誤認→マイグレーションを最初から当てようとする→既に存在するテーブル名で作成しようとしてエラーとなる。

半日かけても原因が分からず、__MigrationHistoryが壊れてしまったのかもしれないと思い込むことにする。一度Rollbackなんてしたからその時おかしくなったのだろうか。

今回の変更は新規テーブルの追加のみだったのですが、カラム数と外部キーが多く手動はちとめんどくさいので以下の手段で。

1. MySQLに新しいデータベース(スキーマ)を作成。Entity Frameworkで用いるユーザーに必要な権限を与える。
2. App.configのConnection Stringを新しいデータベースを対象とするように書き換える。この時のApp.configは開始プロジェクトのもの。
3. Update-Database実行。新しいデータベースにテーブルが作成される。
4. 新しいデータベースからマイグレーションで追加されるテーブルと__MigrationHistoryをデータ付きでdump。

$ mysqldump -uroot -p -hlocalhost 新データベース名 __MigrationHistory 追加テーブル1 追加テーブル2 ... > migration.mysqldump

5. 既存データベースにリストア

$ mysql -uroot -p
mysql> use 既存データベース
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> drop table __MigrationHistory;
Query OK, 0 rows affected (0.82 sec)

mysql> source migration.mysqldump

ConnectionStringを元データベースに戻し、Update-Database -Scriptを実行(-Scriptオプションは実際に実行されないように)でさらに適用するマイグレーションが無いことを確認して完了。

[余談] 今回マイグレーションかける直前にmysqlのディレクトリのスナップショットを取ってあったので焦らずに済んだのですが、普段取らないのになぜ今回取る気になったのだろう？

[参考]

• mysqldumpの使い方 バックアップ＆リストア編 基本の章(ライズウィル)

設定のバックアップ取ってなかった (T^T)

基本USBメモリに対してはリードオンリーのシステムだからそうそう壊れないだろうと思ってたのですが、I/Oエラーというメッセージが。同容量のUSBメモリにddでコピーしてみたのですが、Pythonのファイルが破損したようで起動中にエラーで止まる。そこに同バージョンのFreeNAS上書きしたら設定全部初期化された状態。

どうせ設定しなおしならとFreeNASを9.2から9.3に上げたのですが、/のファイルシステムがufsからZFSに変わったんですね(同時にパーティションテーブルもGPTに)。ん? ZFS…ミラーリングできるということ? てことで8GBのメモリ2本差して9.3インストール時に両方指定すると、ミラーリング構成になっているっぽい。

どうもufsの頃から可能だったようですが全然知らなかった。NASなんて長期間耐久性求められるOSをUSBメモリになんて怖いことさせるなと思ってたのですが、こういう仕掛けだったんですね。

データとJailを保存するZFSは無事だったのと、初めて構築した時のメモを残してあったので、IPアドレス・NTP・ユーザー・CIFS・Jail rootを設定しなおしたらあっさり復活したのが不幸中の幸い。そのうちホットスペア用にもう一本USBメモリ挿すことにしよっと。

行数150M、サイズ550GBなんていう一枚テーブルをinnodbで作ってしまいました。4TB HDD使ってるのでまだまだ溜め込めますが、こんな量のデータを1つのテーブルに入れることが何か間違っているような気がする。

こうなるとインデックス無しではまともにデータは取り出せませんので、まだテーブルが小さかった頃に数個作ってありました。で、恐れていた事態、インデックスの追加。幸いにもMySQL 5.6ではテーブルをロックせずにインデックスを追加・削除できる ようになったので、何日かかるかわからないけどcreate index文を実行。翌朝見ると異常終了orz

そういえば昨日の帰り際、MySQLのCPU使用率が10%前半に落ちてたな(コマンド開始時は30～50%)、メモリが足りないのかと思い、innodb_buffer_pool_size を2GB→6GBに増やして再挑戦。mysqldは順調に実メモリは消費しましたが、仮想メモリに手を出す様子はなし。

しばらく様子を見ていると、/の入っているHDD残量が少しずつ減っているのを発見。ですが前述の通り仮想メモリは増えてない。はて?

ネットで情報を探していると、たどり着いたのがこれ 。

tmpdirについて少し補足します。MySQLがtmpdirに作成した一時ファイルはlsなどのコマンドでは見ることができません。これはMySQLが一時ファイルを作成したあと、すぐに削除してしまうためです。 LinuxなどのOSでは、ファイルを削除してもそのファイルをオープンしているプロセスがある限り実際の削除は行われません。逆に言えば、こうしておくことでプロセス終了時に一時ファイルが自動的にクリーンアップされるというわけです。lsofコマンドであればMySQLが作成した一時ファイルを確認することができます。

書かれている通りにlsofをやってみると

# lsof -p 2249
COMMAND  PID  USER   FD   TYPE             DEVICE     SIZE/OFF   NODE NAME
(省略)
mysqld  2249 mysql   39u   REG               0,39   5445255168   3534 /var/tmp/mysql.zUtW7u/ibDLGxdb (deleted)

たすかに～。/var/tmpにディレクトリを作っていてサイズが増えていっているけど、lsで/var/tmp/mysql.zUtW7uを見ても空っぽ。増える速度はおおよそ20GB/日(画像参照)。/の容量からして昨晩使い果たして落ちたという理由は合点がいく。

応急策としてiSCSIサーバから800GB融通してもらって/に追加。btrfsなのでインデックス作成終わったら外そうと思ってますが、今考えたら追加800GB単独でフォーマットして/var/tmpにマウントした方が安全だったな…

そのほかの環境

• CPU: Haswell Xeon 3.5GHz
• OS: OpenSUSE 13.2 (VMware ESXi 5.5上)
• DBMS: MySQL 5.6.17-2.1.12 (yastにてインストール)
• ファイルシステム: btrfs (OS用に10GB、MySQL用に4TB)
• VMのメモリ: 4GB→8GB

[参考]

• MySQL 5.6における大量データロード時の考慮点 (SH2の日記)
• Optimizing MySQL Indexes (sitepoint)
• The InnoDB Buffer Pool (MySQL)

[2015/6/26 追記]/var/tmp増量後に再挑戦も翌朝失敗。忘れたころにやってくるOOM Killer 。topで見るとメモリを12GBほど要求しているらしい。swap増量、/proc/(mysqldのPID)/oom_adjに-17を書き込んで応戦、9時間後に3度目の正直で成功。