watanabe■背景と経緯

1億件以上(1レコード61バイト)のデータを復元、load data infileしようとしている途中、30分から1時間ほどがりがり動いているように見えているけれども、突然mysqldプロセス停止、という現象を何度も繰り返しているうちに、そのうちmysqldプロセスが起動しなくなった。
エラーがないのでどうしようもなく、serverだけ再インストールすることに。
ちなみに、エラーログはもちろん/etc/my.cnfで指定済み。起動時になんの数値が知らんけど100ぐらいまで数えている内容。起動せずに数値だけ記録されても意味ねぇ。
[code lang=”sql” light=”true”]
130708 17:07:28 InnoDB: Starting an apply batch of log records to the database…
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 9
3 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
130708 17:07:57 InnoDB: Rolling back trx with id 500, 63973706 rows to undo
130708 17:07:57 InnoDB: Waiting for the background threads to start
[/code]
それでmysqlのrun levelを変更して起動を試みたけど失敗
/etc/my.cnfに次の行を追加。
[code lang=”sql” light=”true”]
innodb_force_recovery=1
[/code]
そして1->4にしても失敗
[code lang=”sql” light=”true”]
innodb_force_recovery=4
[/code]
ものすごくよほどのことです。
これで直ることも多いんだけど直らなかった。

■準備

[code language=”bash”]
>rpm -qa |grep mysql
mysql-connector-odbc-5.1.5r1144-7.el6.x86_64
mysql-devel-5.5.32-1.el6.remi.x86_64
mysql-libs-5.5.32-1.el6.remi.x86_64
mysql-5.5.32-1.el6.remi.x86_64
php-mysql-5.4.17-1.el6.remi.x86_64
mysql-server-5.5.32-1.el6.remi.x86_64
[/code]
症状的にmysql-serverだけでいいかと思って、そのrpmを一度消して再DL、rpmコマンドで入れることに。
[code language=”bash”]
>rpm -e mysql-server
[/code]
wgetでなく上記とまったく同じやつでないと依存で引っかかるので、
海外から探して上記mysql-serverのrpmだけDLした。
そして
[code language=”bash”]
>rpm -ivh MySQL-server*
>mysql_secure_installation
[/code]
rpmコマンドでは面倒なのでワイルドカードを使った。
適当にセキュア設定して(社内LANのみリモート接続おKとか)
[code language=”sql”]
mysql> grant all privileges on dbname.* to root@"192.168.2.%"
-> identified by ‘password’ with grant option;
Query OK, 0 rows affected (0.00 sec)

[/code]

■mysqlプロセス再起動と設定

どきどきで再起動しましたよ。
[code language=”bash”]
>/etc/rc.d/init.d/mysqld start
[/code]
普通に起動したのでcreate DBした。
そしてload data infileを再び実行。
待つ、待つ、待つ・・・50分経過。はい、mysqldプロセス落ちました。現象は変わらないけど、
プロセス再起動は正常。
プロセスを手動停止して、ログファイルを拡張することにした。

■ib_logfileの拡張

/var/lib/mysql/のib_lofile0~2をデフォルトの256Mから1Gに変更してみることに。
ます、/etc/my.cnfの該当箇所を変更。
[code langage=”bash”]
innodb_log_file_size = 1G
[/code]
innodb_log_files_in_group は3より大きくしても無駄なのでそのまま。
それから既存ファイルの退避
[code langage=”bash”]
# mv ib_logfile0 ib_logfile0_org
# mv ib_logfile1 ib_logfile1_org
# mv ib_logfile2 ib_logfile2_org
[/code]
退避したのでもとのファイルは無くなっわけだけど、プロセス起動時にmysqldが作ってくれる。

他の大きく変更しているパラメータはこれ。
[code langage=”bash”]
innodb_buffer_pool_size = 18G
innodb_flush_log_at_trx_commit = 2
[/code]
サーバには32Gメモリがあるので、しかもDB専用なのでinnodb_buffer_poolをもっとあげてもいいと思っているけど、
この時点ではload用に上記パラメータをあげたのでbuffer_poolは下げた。
それから
[code language=”bash”]
>/etc/rc.d/init.d/mysqld start
[/code]
問題なくプロセス起動。ib_dataも作ってくれている。ちなみにtopコマンドを見ると、このパラメータ変更前にはゼロだったswapが数十MB出現していた。
こはいかに?特に気にしないことにする。(仕組みがわからないので)
→ここで放置したために今後スラッシングからの影響は延々とついてまわるのだった。。。
vol2へ続く。