（6.2までは、ざっくりと「メモリテーブル見積」*10。メモリを32GB積んで、30GBほどをMySQL Clusterに割り当てたら、ざっくり300GBほどのHDDがあると良い。）
というわけで、MySQL Clusterのバックアップは「取りっぱなし」では、HDD容量を圧迫するので、MySQL Clusterのメンテナンス用スクリプトを作ってみた。
#!/bin/shbkupdir=`find /export/home/mysql-cluster/BACKUP/ -name "BACKUP*" |wc -l`
echo "The number of backup dir under BACKUP is:" $bkupdir
if [ $bkupdir -gt 0 ];
thencp -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へ発行される。
]]>sql_mode=TRADITIONALではmysql_install_dbが失敗するので要注意。
sql_modeをデフォルトに戻せば、OK。
以前もハマった記憶があるのだけど。
]]>通常、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リソースを最上位に持ってくれば、問題ないハズ。（未だ試せてない。来週試す予定。）
]]>ゾーンに対して定義したエスケープシーケンスを使用します。エスケープシーケンスを定義していない場合は、次のデフォルトのエスケープシーケンスを使用します。]]># ~.
・データ書き込み時に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では設定できないので、下のレイヤーで冗長化する。（ボンディングなど）
]]>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 YYYYMMDD_xx_xx.log
exitでscriptコマンド終了。
MySQL 5.1--Generally Available (GA) release for production use
https://enterprise.mysql.com/software/enterprise.php
トップページが、5.1になっています。
mysql.com上にもリリースは一切なし。
まだニュースにも流れていないようだけど、なんでそんなにこっそり？？？
Monty says: Oops, we did it again (MySQL 5.1 released as GA with crashing bugs)
Montyが、「5.1リリース前に直すべきだった（けど直せなかった）バグの一覧」
をまとめています。
ということで、「5.1はまだ製品版には ほど遠いけど、諸般の事情で製品版ということに
なった」ようです。
タイトルは、「5.0はGAリリース後に深刻なバグがいくつも見つかったけど、
また同じことをやってしまった。」という意味でしょうか。
「5.1を使う前に、十分テストしてから使いましょう」とのことです。
]]>正解：
1)SQLNodeの再起動時
2)SQLNode稼働中に全てのDataNodeが停止した場合
上記ケースにて、当該SQLNodeのバイナリログにLOST_EVENTSが出力される。
SQLNode停止から再起動までの間に発生した他のSQLNodeからの更新を、再起動したSQLNodeのバイナリログファイルに反映でき ないことによる不整合の発生を回避することを目的として。
「データが同じならば、とりあえずSET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;で進めてしまう」が対処方法。
[(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.20.100.22
Master_User: rep
Master_Port: 3307
Connect_Retry: 60
Master_Log_File: h2-2.000005
Read_Master_Log_Pos: 106
Relay_Log_File: h1-relay-bin.000003
Relay_Log_Pos: 246
Relay_Master_Log_File: h2-2.000002
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1590
Last_Error: The incident LOST_EVENTS occured on the master. Message: mysqld startup
Skip_Counter: 0
Exec_Master_Log_Pos: 106
Relay_Log_Space: 1988
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1590
Last_SQL_Error: The incident LOST_EVENTS occured on the master. Message: mysqld startup
1 row in set (0.00 sec)
MySQL :: MySQL 5.1 リファレンスマニュアル :: 3.3.2 オプションファイルの使用
適切な動作のためには、これらのオプションの各々は速やかにコマンド名に続かなければなりません。
分かりにくい日本語だ。
MySQL :: MySQL 4.1 リファレンスマニュアル :: 4.1.2 my.cnf オプション設定ファイル
注意: これらのオプションは、コマンド行の最初に置く必要があります。
こちらの方が分かりやすい。
]]>svcadm restart ssh
]]>