メモ帳

MySQL Clusterは、メモリテーブルであっても、かなりディスク容量を消費する。

（6.2までは、ざっくりと「メモリテーブル見積」*10。メモリを32GB積んで、30GBほどをMySQL Clusterに割り当てたら、ざっくり300GBほどのHDDがあると良い。）

というわけで、MySQL Clusterのバックアップは「取りっぱなし」では、HDD容量を圧迫するので、MySQL Clusterのメンテナンス用スクリプトを作ってみた。

#!/bin/sh

bkupdir=`find /export/home/mysql-cluster/BACKUP/ -name "BACKUP*" |wc -l`

echo "The number of backup dir under BACKUP is:" $bkupdir

if [ $bkupdir -gt 0 ];
then

cp -pr /export/home/mysql-cluster/BACKUP/* /xxxxx/mysql-cluster-backup/
rm -r /export/home/mysql-cluster/BACKUP/*
find /xxxxx/mysql-cluster-backup/ -mtime +0 -name "BACKUP*" -exec rm -r {} \;

else
echo "The BACKUP-X directory is none."
fi

想定シナリオは以下の通り。

・1日に1回（MySQL Clusterの）バックアップを取得する

・バックアップファイルは、/export/home/mysql-cluster/BACKUP/以下に1世代、/xxxxx/mysql-cluster-backup以下に1世代、の合計2世代保持

・各Data Nodeで実行する

Data Nodeは通常冗長化構成をとるので、「冗長化されているData Nodeが全てダウン」かつ「LCPでフラッシュしているイメージが使用不可でクラッシュリカバリできない」場合に、初めてバックアップファイルが必要となる。

なので、とりあえずは2世代で。

ちなみに、Management Nodeを2重化しておけば、バックアップ取得は、以下で可能。

ndb_mgm -e -c "xxxxx;yyyyy" "start backup"

xxxxxのManagement Nodeがダウンしているときは、yyyyyのManagement Nodeを経由して、バックアップコマンドがData Nodeへ発行される。

MySQL Bugs: #34159: mysql_install_db fails with sql_mode=TRADITIONAL

sql_mode=TRADITIONALではmysql_install_dbが失敗するので要注意。

sql_modeをデフォルトに戻せば、OK。

以前もハマった記憶があるのだけど。

MySQLのレプリケーションを構成して、マスターをLifeKeeperで冗長化して、スレーブはLifeKeeperで管理している仮想IPに対してレプリケーションを組んでいる環境でのハナシ。

通常、MySQLレプリケーション構成時にマスターがダウンすると、スレーブはこのようなメッセージと共に、即座にコネクションが切断される。

mysql> 081210 20:16:15 [Note] Slave: received end packet from server, apparent master shutdown:
081210 20:16:15 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'h-bin.000028' at postion 192
081210 20:16:15 [ERROR] Slave I/O: error reconnecting to master 'rep@172.20.100.113:3306' - retry-time: 60 retries: 86400, Error_code: 2013

mysqladmin shutdownなどでマスターを停止すると、停止処理の中に、コネクション切断も入っている。

ただし、LifeKeeperのMySQLリソースとIPリソースの依存関係によっては、即座にコネクションが切断されない場合がある。

IPリソースを最上位に持ってくると、フェールオーバーしても、古いTCP/IPコネクションが維持されたまま（Established）となって非常によろしくない。
さらに、LifeKeeperでフェールオーバーしても、フェールオーバー先のマスターのMySQLに接続しない。

（LifeKeeperのGUI経由でのみ発生する問題だったので、IPリソースを落としてからMySQLリソースを落とす、という順番に問題がある模様。ただし、この場合もslave_net_timeout=30などで対処は可能。リレーログがさくさくローテートしてしまうけど、運用上は問題ないはず。）

セオリー通り、MySQLリソースを最上位に持ってくれば、問題ないハズ。（未だ試せてない。来週試す予定。）

ゾーンのインストールと構成 (Sun Cluster Data Service for Solaris Containers ガイド) - Sun Microsystems

ゾーンに対して定義したエスケープシーケンスを使用します。エスケープシーケンスを定義していない場合は、次のデフォルトのエスケープシーケンスを使用します。

# ~.

・SDRとVIPなどのリソースが同時に障害→LKがリソースを立ち上がられない

・データ書き込み時にSDRに障害→15分ほど書き込みできない状態が発生

（http://sios-steeleye.sios.com/modules/smartsection/item.php?itemid=32
）ただしLinux Kernel 2.6.24はRedHat 5でサポートされない。

・NIC障害時にeth 0, eth 1両方つぶれるものがあるので注意

結論

・NIC*3が最低必要

eth0：HB1, VIP
eth1とeth2でボンディング：SDR, HB2

・SDRの冗長構成をLifeKeeperでは設定できないので、下のレイヤーで冗長化する。（ボンディングなど）

HeartbeatIntervalDbDb

HeartbeatIntervalDbApi

ともにデフォルトで1.5秒

MySQL :: MySQL 5.1 リファレンスマニュアル :: 14.4.4.5 Defining Data Nodes

おかしくなることもある。

PK指定なしのテーブルt2では、二重にデータが挿入されてしまったが、PKありのテーブルt1では、特におかしな挙動とはならなかった。

[test]> show create table t2\G
*************************** 1. row ***************************
Table: t2
Create Table: CREATE TABLE `t2` (
`a` int(11) DEFAULT NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

[test]> show create table t1\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`a` int(11) NOT NULL,
`b` int(11) DEFAULT NULL,
PRIMARY KEY (`a`)
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

エラーログ
スロークエリログ
などなど、バイナリログ以外は自動でローテートしないので、適宜

mv <ファイル名> <新しいファイル名>
mv <ファイル名> <新しいファイル名>
flush logs;

が必要

レプリケーション環境でのバイナリログのメンテナンスは二通り。

・expire_logs_daysを設定しておく

・purge master logs to...を発行する

最も簡単なのがexpire_logs_days = 7 (days)などと設定しておくこと。

確実さを好むならば、スレーブのshow slave status\GのMaster_Log_Fileを指定する。

スレーブが複数存在する場合は、一番番号の若いMaster_Log_Fileを指定する。

script コマンドで作業ログを取得する。

script YYYYMMDD_xx_xx.log

exitでscriptコマンド終了。