2012年12月28日金曜日

postfix 設定 その1 メールの送信


①postfixをインストールします。(yumを使います)
yum -y install postfix

さてまずは、最低限の設定としてイントラから 外側宛てにメールを送れるように設定をします。 

②設定ファイルの変更。
「/etc/postfix/main.cf」を編集します。
mydomain = localhost.localdomain
myhostname = localhost.localdomain
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain
  • 「mydomain」:自分部分のドメイン名を記述します。 mydestination のデフォルト値で「localhost.$mydomain」として使用されていたりします。 「myhostname」を適切に設定していれば、特にいじる必要はない項目です。
  • 「myhostname」:自ホスト名を設定します。さまざまな部分で使用される値なので、DNSに登録されているFQDN形式の値を設定します。
  • 「myorigin」:経由されたメールサーバーを特定するのに確認したりします。 今はメールサーバーが一つなので$mydomainを入れておきます。
  • 「mydestination」:最終的な宛先となるドメインを指定します。 @から後ろの部分がこの設定値と一致したメールを自ホスト内でメールを処理するようになります。今は送信のみのテストなのでデフォルト値のままにしておきます。
③postfixを起動します。
/etc/rc.d/init.d/postfix start
※既に起動中でmain.cfだけ変更した場合はリロードします。
/etc/rc.d/init.d/postfix reload

■postfixが上手く起動できない場合
OSのデフォルト設定でsendmailが自動起動している場合がありますので、sendmailを止め自動起動設定を外します。
/etc/init.d/sendmail stop
/sbin/chkconfig sendmail off
sendmail が停止できたら、Postfix を起動。自動起動の設定もしておきます。
/etc/init.d/postfix start
/sbin/chkconfig postfix on
また、このままの状態だとデフォルトのメールサーバーが sendmail になってしまっているので、これをPostfixに変更します。
/usr/sbin/alternatives --config mta

④postfixが起動出来たら、実際にメールを送信してみます。
echo "This is test mail. hello hello" | mail test@xxxxx.ne.jp
「test@xxxxx.ne.jp」は普段実際に使用しているメールアドレスを入れてください。 
 実際にメールが届けば設定は成功です。


本項目は下記ページを参考にさせて頂きました。
http://www.tmtm.org/postfix/tutorial/index.html




2012年12月27日木曜日

MySQLの監視テンプレートを適用する

zabbixでMySQLを監視するためにテンプレートを適用したいと思います。

zabbixをインストールしただけではMySQLのテンプレートは無いので、
以前の記事を参考に、監視テンプレート追加してください。

また、MySQLの監視を行いたいサーバーにzabbixエージェントがインストールされていない場合には
こちらの記事を参照してインストールまで行ってください。

■手順1
MySQL監視対象サーバーでzabbixエージェントの設定の編集。
vi /etc/zabbix/zabbix_agentd.conf

#Zabbixサーバーからのリモートコマンドを許可するかどうかを設定します。0:許可しない,1:許可する
EnableRemoteCommands=1

#実行されたシェルコマンドの警告をログに記録するかを指定。0:無効,1:有効
LogRemoteCommands=1

#処理がタイムアウトになる秒数を設定(デフォルト3秒)
Timeout=10

#includeされるディレクトリの確認(デフォルト値のまま)
Include=/etc/zabbix/zabbix_agentd.d/

■手順2
zabbix-agentの再起動
# /etc/init.d/zabbix-agent restart
Shutting down zabbix agent:                                [  OK  ]
Starting zabbix agent:                                     [  OK  ]
■手順3
MySQL用のUserParametersを追加する
/etc/zabbix/zabbix_agentd.d/にはデフォルトでサンプル用に
serparameter_examples.conf、userparameter_mysql.confが置かれている

UserParameterの書式
#基本
UserParameter=キー名,コマンド
#Webインターフェイスから引数を受け取って、コマンドを実行する場合
UserParameter=アイテム設定のキー名[*],コマンド
キー名は、Webインターフェイスとの紐付け用の名前になる?

MySQLの監視用の設定ファイルを新規に作成する。
vi /etc/zabbix/zabbix_agentd.d/userparameter_mysql_ex.conf
##################################
#
# MySQLの監視用
#
##################################
#これまでに記録された同時接続数の最大値
UserParameter=mysql.max_connections,/usr/bin/mysqladmin variables|grep max_connections|awk '{print $4}'
#現在開いている接続の数
UserParameter=mysql.threads_connected,/usr/bin/mysqladmin extended-status|grep Threads_connected|awk '{print $4}'
#接続を処理するために生成されたスレッド数。起動してから生成されたスレッドの数。この値が大きい場合はthread_cache_sizeの値を大きくした方が良いかも。
UserParameter=mysql.threads_created,/usr/bin/mysqladmin extended-status|grep Threads_created|awk '{print $4;}'
#スリープ状態になっていないスレッド数
UserParameter=mysql.threads_running,/usr/bin/mysqladmin extended-status|grep Threads_running|awk '{print $4;}'
#スレッドキャッシュでキャッシュされているスレッドの数。
UserParameter=mysql.thread_cache_size,/usr/bin/mysqladmin variables|grep thread_cache_size|awk '{print $4}'
#
UserParameter=mysql.connections,/usr/bin/mysqladmin extended-status|grep Connections|awk '{print $4;}'
#問い合わせ平均応答秒数
UserParameter=mysql.query_per_sec_avg,/usr/bin/mysqladmin status|awk '{print $22}'
※/usr/bin/mysqladminの部分は、各環境にインストールされているパスにあわせる。パスの確認はwhichが使える。
# which mysqladmin
/usr/bin/mysqladmin

■手順4
zabbix-agentの再起動
# /etc/init.d/zabbix-agent restart
Shutting down zabbix agent:                                [  OK  ]
Starting zabbix agent:                                     [  OK  ]

■手順5
設定したUserParameterが正常に動いているか確認する。
# /usr/bin/mysqladmin variables|grep max_connections|awk '{print $4}'
151
# /usr/bin/mysqladmin extended-status|grep Threads_connected|awk '{print $4}'
2
# /usr/bin/mysqladmin extended-status|grep Threads_created|awk '{print $4;}'
4
# /usr/bin/mysqladmin extended-status|grep Threads_running|awk '{print $4;}'
2
# /usr/bin/mysqladmin variables|grep thread_cache_size|awk '{print $4}'
8
# /usr/bin/mysqladmin extended-status|grep Connections|awk '{print $4;}'
12666
# /usr/bin/mysqladmin status|awk '{print $22}'
0.146

■手順6
zabbixサーバーからUserParameterが取得できているか確認する。
$ /usr/bin/zabbix_get -s 監視対象のMySQLサーバーのIPアドレス -k mysql.max_connections
151
$ /usr/bin/zabbix_get -s 監視対象のMySQLサーバーのIPアドレス -k mysql.threads_connected
2
$ /usr/bin/zabbix_get -s 監視対象のMySQLサーバーのIPアドレス -k mysql.threads_created
4
$ /usr/bin/zabbix_get -s 監視対象のMySQLサーバーのIPアドレス -k mysql.threads_running
2
$ /usr/bin/zabbix_get -s 監視対象のMySQLサーバーのIPアドレス -k mysql.thread_cache_size
8
$ /usr/bin/zabbix_get -s 監視対象のMySQLサーバーのIPアドレス -k mysql.connections
12907
$ /usr/bin/zabbix_get -s 監視対象のMySQLサーバーのIPアドレス -k mysql.query_per_sec_avg
0.146

ここまでで、監視対象サーバーの設定は完了になります。
次に、Webインターフェイスの設定になります。

ここからはZabbixサーバーのWebインターフェイスの設定になります。
■手順1
「設定」→「ホスト」で、ホスト一覧から、MySQLのテンプレートを適用したいサーバーのホスト名をクリックし、ホストの設定画面を開きます。例では「kagoya vps mysql master」を指定します。

■手順2
ホストの設定画面が開いたら右上にある、「リンクしているテンプレート」の枠にある、「追加」のボタンを押して、テンプレート一覧から「Template_JP_App_MySQL」のチェックボックスにチェックし、一番下にある「選択」を押して、ホスト一覧画面に戻る。



■手順3
手順2で「リンクしているテンプレート」の枠内に、先程指定した「Template_JP_App_MySQL」が追加されているの確認し、左下にある「保存」を押して、ホスト一覧へ戻ります。


■手順4
ホスト一覧に先程指定した「kagoya vps mysql master」の行にあるテンプレートの欄に、
追加したテンプレートの「Template_JP_App_MySQL」が表示されている事を確認する。
また、ステータスが有効になっていることと、エージェントの状態のZが緑色であることを確認しておく。
問題が無ければ、「kagoya vps mysql master」の行にある「アプリケーション」の枠のアプリケーションのリンクをクリックして、アプリケーションの設定画面を開く。

■手順5
右上にあるホストのプルダウンが「kagoya vps mysql master」を選択されている事を確認し
Template_JP_App_MySQL:MySQLの行にあるアイテムのリンクをクリックして、アイテムの設定画面を開く。


■手順6
アイテムの設定画面で、各行のステータスが「無効」になっているもののリンクをクリックして、有効に変更する。


■手順7
「監視データ」→「最新データ」を開き、右上のホスト一覧で「kagoya vps mysql master」を選び、
最新データの地位欄からMySQLをクリックすると、監視対象サーバーで設定した各値が収集された最終時刻などの結果が表示されています。


■手順8
「監視データ」→「グラフ」で右上のホスト一覧のプルダウンから、
「kagoya vps mysql master」を選択して、その横のグラフのプルダウンから
「MySQL Connections」や「MySQL Threads」を選択すると、集計結果のグラフが確認できます。

以上です(`・ω・´)ゞビシッ!!
参考URL

ajaxfileupload

2,3年ほど前に作成したサイトで利用していたajaxで画像のアップロード用の
jquery用ライブラリーの「ajaxfileupload」がIE6,IE7,IE8では動作するのに、
IE9では正しく動いていなかったことが発覚:(;゙゚'ω゚'):

ライブラリーの公式サイトを見ると、
最新バージョンでは修正されてるっぽいですが、jqueryのバージョンなどの関係のせいか、
既存のサイトでは正しく動かなかったため、一部抜粋して修正を行いました。

IE9でのエラー内容は次のようになっていました。
SCRIPT5022: DOM Exception: INVALID_CHARACTER_ERR (5) 
ajaxfileupload.js, 行 11 文字17
ライブラリーの修正箇所は次のようにしました。
#11行目付近のこの行を
var io = document.createElement('<iframe id="' + frameId + '" name="' + frameId + '" />');
↓
#ie9 bug fix patch
if ($.browser.msie && $.browser.version=="9.0") {
	var io = document.createElement("iframe");
	io.setAttribute("id", frameId);
	io.setAttribute("name", frameId);
} else {
	var io = document.createElement('<iframe id="' + frameId + '" name="' + frameId + '" />');
}
ъ(゚Д゚)グッジョブ!!
参考URL

2012年12月26日水曜日

iptables

iptablesの機能
  • パケットフィルタリング(IPv4用)機能
  • ネットワークアドレス変換(NAT)機能
  • ファイアウォール機能


◆起動状態確認
#/sbin/chkconfig --list iptables
◆再起動
#/etc/rc.d/init.d/iptables restart
◆起動
#/etc/rc.d/init.d/iptables start
◆停止
#/etc/rc.d/init.d/iptables stop
◆確認
#/sbin/iptables -L
#/sbin/iptables --list


◆設定

◇直接、ファイルを編集して設定する手順

1.ファイルを直接編集する
#vi /etc/sysconfig/iptables
-A INPUT -s 111.111.111.111/32 -p tcp -m tcp --dport 3306 -j ACCEPT
2.再起動する
#/etc/rc.d/init.d/iptables restart

◇コマンドで設定する手順
#/sbin/iptables -A INPUT -s 111.111.111.111 -p tcp --dport 3306 -j ACCEPT
#service iptables save
service iptables saveを実行することで/etc/sysconfig/iptablesに書き込まれる。
(直接、ファイルを編集する手順と同じ)
書き込んでおかないと再起動で消える。


◆/etc/sysconfig/iptablesの内容
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
  • 上記4行は固定で記述する
  • *filter・・・パケットフィルタリング
  • INPUT/FORWARD/OUTPUT ACCEPT・・・・INPUT/FORWARD/OUTPUTを許可(ACCEPT)する(デフォルト全許可)
  • [0:0]・・・パケット・バイトカウンタ。iptables起動時に[0:0]からスタートして、ルールにマッチしたパケット数とバイト数がカウントされていく。
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  • -A INPUT・・・入力パケット(INPUT)のルールを追加する(-A)
  • -m state --state RELATED,ESTABLISHED・・・関連パケット(RELATED)、継続パケット(ESTABLISHED)の
  • -j ACCEPT・・・パケットの通過を許可(ACCEPT)する
  • (※-m=拡張モジュール。stateオプション指定するための定義)

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
  • -A INPUT・・・入力パケット(INPUT)のルールを追加する(-A)
  • -p tcp・・・TCPプロトコルの
  • -m state --state NEW・・・接続パケット(NEW)の
  • -m tcp --dport 22・・・ポート番号(TCP22=SSH)の
  • -j ACCEPT・・・パケットの通過を許可(ACCEPT)する


-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-m state --state NEW、ESTABLISHED、RELATEDについて
上記は、全プロトコルRELATED、ESTABLISHEを許可し、TCP22(SSH)のNEWを許可している(入力パケット) パケットは、それぞれ下記の通り。
  • NEWはACKフラグがセットされていないパケットやICMPのecho Requestなどの接続パケット(下記1)
  • ESTABLISHEDは、すでに接続が確立している継続パケット(下記2~8)
  • RELATEDはるFTP-dataなどの既存コネクションの関連パケット
  • INVALIDは上記以外のパケット

TCPの通信での接続(スリーウェイ・ハンドシェイク)~切断について、接続パケット(NEW)と継続パケット(ESTABLISHED)は下記の通り
  1. 接続元からサーバへSYNパケット(SYN=1/ACK=0)が送信される(接続要求)・・・NEW
  2. サーバは接続元へSYN/ACKパケット(SYN=1/ACK=1)を返信する(接続許可)・・・ESTABLISHED
  3. 接続元からサーバに、ACKパケット(SYN=0/ACK=1)が送信される(接続開始)・・・ESTABLISHED
  4. データパケット(SYN=0/ACK=1)送受信・・・ESTABLISHED
  5. サーバから接続元へACK/FINパケット(ACK=1/FIN=1)を送信する(切断要求)・・・ESTABLISHED
  6. 接続元からサーバへACKパケット(ACK=1/FIN=0)を返信する(切断許可)・・・ESTABLISHED
  7. 接続元からサーバへACK/FINパケット(ACK=1/FIN=1)を返信する(切断通知)・・・ESTABLISHED
  8. サーバから接続元へACKパケット(ACK=1/FIN=0)を送信する(切断)・・・ESTABLISHED

pingの通信
  1. 接続元からサーバへICMPのecho requestパケットが送信される(リクエスト)・・・NEW
  2. サーバから接続元へecho replyが返信される(レスポンス)・・・ESTABLISHED?

FTP-data
  • FTP通信は、制御用コネクションとデータ転送用コネクションの2つのTCPコネクションを利用する
  • 制御用コネクションで接続を確立し、データ転送用コネクションでデータを転送するが、この際の制御用コネクションに関連するデータ転送用コネクションがRELATED(関連パケット)になる。

-A INPUT -p icmp -j ACCEPT・・・1
-A INPUT -i lo -j ACCEPT・・・2
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT・・・3
  1. -p icmp・・・ping入力許可
  2. -i lo・・・ローカル(自分自身)からの入力許可
  3. -m tcp --dport 80・・・http入力許可

-A INPUT -j REJECT --reject-with icmp-host-prohibited
  • 最後に上記のルールにマッチしないパケットは接続拒否にする(ICMPのhost-prohibitedを返信し接続拒否)

COMMIT
  • ファイルの最終行に記述

まとめ
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 10050 -j ACCEPT
-A INPUT -s 111.111.111.111/32 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT


参考URL

slaveの再設定、追加(オンラインバックアップ)

既にレプリケーションが設定されているslaveに対して、フルバックアップからレプリケーションを再設定を行う。
方法としてはいくつかあるみたいで、オンラインバックアップ、コールドバックアップ、スナップショットなどがあるそうです。

・オンラインバックアップ
mysqlの停止は必要無し。ダンプとリストアを行うため時間がかかる。
・コールドバックアップ
mysqlの停止が必要。オンラインバックアップよりかは早い?
同一サーバー間の再構築用はこちら。別サーバー間の再構築用はこちら
・スナップショット
mysqlの停止は必要なし。OSにスナップショット機能が必要。一番早い?

今回はmasterのフルバックアップファイルを利用した、オンラインバックアップを利用したいと思います
基本的には以前の記事のレプリケーションの設定の手順4あたりからやれば問題なさそうですが補足情報になります。

別サーバーで、レプリケーションが行われているmysqlからダンプして
フルバックアップファイルを利用して、slaveを設定しなおす場合に、
mysqlの接続アカウント情報も書き変わってしまう。

そのため、元々masterに設定されていた接続アカウントと
ダンプファイルのアカウント情報が違う場合には、アカウント情報を再設定してあげる必要がある。

たとえば、masterに作られていたレプリケーション用の接続アカウント情報が変わってしまったことで、
正しく同期処理が行えなくなってしまう、アプリ側から接続我行いなどが発生してしまう。

mysql> select user,host from mysql.user;
+------+----------------------+
| user | host                 |
+------+----------------------+
| root | 127.0.0.1            |
| root | ::1                  |
|      | localhost            |
| root | localhost            |
|      | ***.kagoya.net |
| root | ***.kagoya.net |
+------+----------------------+
6 rows in set (0.00 sec)
↓
mysql> select user,host from mysql.user;
+--------+------------+
| user   | host       |
+--------+------------+
| *****  | 10.255.7.% |
| *****  | 10.255.7.% |
| *****  | 10.255.7.% |
| *****  | 10.255.7.% |
| *****  | 10.255.7.% |
| *****  | 10.255.7.% |
| *****  | 10.255.7.% |
| ****   | 10.255.7.% |
| *****  | 10.255.7.% |
| root   | 127.0.0.1  |
| root   | ::1        |
|        | ****       |
| root   | ****       |
|        | localhost  |
| root   | localhost  |
+--------+------------+
15 rows in set (0.00 sec)
アカウント情報が書き変わった状態で、start slaveを実行しても次のようエラーになってしまう。
(レプリケーション用のアカウント情報が以前のと同じであれば発生しない)

Last_IO_Errno: 1130
Last_IO_Error: error connecting to master 'slave@*******:3306' - retry-time: 10  retries: 86400
フルバックアップファイルを持ってきた構成とサーバーのIPアドレスなどが違った場合に、
接続アカウントのホスト情報などが違って取得できなかったりする。

権限を確認してみるが、
なぜか権限を確認してみるが表示されない・・・orz
mysql> SHOW GRANTS FOR 'アカウント名'@'10.255.7.%';
ERROR 1141 (42000): There is no such grant defined for user 'アカウント名' on host '10.255.7.%'
接続アカウント情報を作り直したが良いのかも?
#権限の削除
REVOKE ALL PRIVILEGES ON *.* FROM 'アカウント名'@'10.255.7.%';

#アカウント削除
DELETE FROM mysql.user WHERE user='アカウント名' AND host='10.255.7.%';

#反映
FLUSH PRIVILEGES;
削除したアカウントを作り直す。
次の例ではmaster側にslaveから繋げるレプリケーション用の接続アカウントを作り直しています。
#master側にレプリケーション用のアカウント作成
#slaveごとに共通のアカウントを利用する場合、
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%' IDENTIFIED BY 'パスワード';
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GRANTS FOR 'repl'@'%';
+-------------------------------------------------------------------------------------------------------------------------------------+
| Grants for repl@%                                                                                                                   |
+-------------------------------------------------------------------------------------------------------------------------------------+
| GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%' IDENTIFIED BY PASSWORD '*A424E797037BF97C19A2E88CF7891C5C2038C039' |
+-------------------------------------------------------------------------------------------------------------------------------------+
#
FLUSH PRIVILEGES;

#masterに作成した接続アカウントがslave側から接続できるか確認
$ mysql -h masterのサーバーIPアドレス -u repl -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5320
Server version: 5.5.27-log MySQL Community Server (GPL) by Remi

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

元々あったレプリケーション用の接続アカウントから変更があった場合には、
slave側でCHANGE MASTER TOを実行する必要がある。
#slaveにリストアするダンプファイルから
#CHANGE MASTER TOで設定するバイナリーログ名と、ポジションを取得する。
head -100 /home/admin/replication_all_dump_20121225_01.sql | grep CHANGE
-- CHANGE MASTER TO MASTER_LOG_FILE='バイナリーログのファイル名', MASTER_LOG_POS=バイナリーログのポジション;

#slave側で設定を変更
CHANGE MASTER TO
MASTER_HOST='マスターのIPアドレス',
MASTER_USER='レプリケーション用の接続アカウント名',
MASTER_PASSWORD='レプリケーション用の接続アカウントのパスワード',
MASTER_PORT=3306,
MASTER_LOG_FILE='バイナリーログのファイル名',
MASTER_LOG_POS=バイナリーログのポジション,
MASTER_CONNECT_RETRY=10;
ユーザーの作成などのコマンドはレプリケーション側でも実行されため、
slave側のユーザーを手動で消した後に、master側の方も消してしまうと、
slave側は既に消えてしまっているのでエラーになり同期がされなくなってしまうので注意!!:(;゙゚'ω゚'):

slaveでエラーが出てしまった場合には、SQL_SLAVE_SKIP_COUNTERを実行して、
1つずつ処理をスキップして解消する!ド━(゚Д゚)━ン!!

スキップごとにをstart slaveを繰り返しながらshow slave status確認し、
Last_SQL_Error:に何もでなくなるまでスキップさせる。
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Query OK, 0 rows affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G

2012年12月25日火曜日

CHANGE MASTER TO

久々にkagoya vpsのテスト環境にログインしてみたら・・・mysqlがとまっとる!!!
何か少し前にサーバーの再起動を行います的なメールが来ていたので、
その影響で止まっていたのかな?

早速、起動を試した際におきた問題の話です:(;゙゚'ω゚'):

masterは簡単に起動できたのですが、
slave側で起動後にslave startを実行してみたらエラーになってしまいました。

エラー内容は次のような内容になっていました。
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: ***********
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 218
               Relay_Log_File: mysql-relay-bin.000006
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 218
              Relay_Log_Space: 214
              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: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 10
1 row in set (0.00 sec)
バイナリーログがなんちゃら~と出ているので、バイナリーログを確認してみることに。
masterのバイナリーログの状態の確認をしてみる。
現在のmasterのバイナリーログの状態は、次のようになっていました。
mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000011 |      107 |              |                  |
+------------------+----------+--------------+------------------+
ただし、先程のslave側の情報を見る限りだと、
*************************** 1. row ***************************
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 218
               Relay_Log_File: mysql-relay-bin.000006
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000010
と、なっているため、slave側はまだ一つ前のバイナリーログを必要としているみたいでした。
slave側ではまだI/Oスレッドがmysql-bin.000010を必要としている?
なので、master側にそのバイナリーログがあるか確認してみることに。
# ls -alt /var/lib/mysql/
合計 28772
drwxr-xr-x  6 mysql mysql     4096 12月 21 11:38 2012 .
-rw-rw----  1 mysql mysql      107 12月 21 11:38 2012 mysql-bin.000011
-rw-rw----  1 mysql mysql       19 12月 21 11:38 2012 mysql-bin.index
-rw-rw----  1 mysql root     15348 12月 21 11:38 2012 mysql-error.log
drwxr-xr-x 17 root  root      4096  9月 28 02:12 2012 ..
無いだと!?・・・:(;゙゚'ω゚'):

ということは、slaveが必要としているバイナリーログがmaster側にないために 為にエラーが出ている感じかな?

恐らく今回の現象的には、master,slaveのサーバーが再起動されたタイミングで、
mysqlが停止され、そのまま数日放置しておいたため、バイナリーログの保存期間を超えてしまったために、
master側を起動した際にログローテートされたタイミングで?mysql-bin.000010が削除されてしまい、
その後に、slaveを起動したことで、slave側はmasterのmysql-bin.000010必要としていたけど、
なくなってしまったことでエラーが発生ということですかね・・・?:(;゙゚'ω゚'):

Google先生に聞いてみたところ、次のような記述を見つけました。

MySQL5.6のmysqlbinlogコマンド
コピーするバイナリログがコピー元サーバから削除されている場合(expire_logs_daysやpurge master logs to等で)はエラーとなります。 ERROR: Got error reading packet from server: Could not find first log file name in binary log index file

ということなので、直すにはコピーするバイナリーログを変更してあげれば(・∀・)イイ!!
先程確認したmasterのバイナリーログの設定情報を元に、
slaveの設定を行います

#マスターのバイナリーログの情報(masterサーバーで実行する)
mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000011 |      107 |              |                  |
+------------------+----------+--------------+------------------+

#ここから下はslave側で実行する。

#slaveの同期停止
mysql> STOP SLAVE; 
Query OK, 0 rows affected (0.00 sec) 

#masterのバイナリーログの情報を設定する
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000011', MASTER_LOG_POS=107;
Query OK, 0 rows affected (0.00 sec) 

#同期開始
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)

#確認
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: *********
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000011
          Read_Master_Log_Pos: 107
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000011
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 107
              Relay_Log_Space: 409
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 10
1 row in set (0.00 sec)
キタ――(゚∀゚)――!!
おまけですが、この復旧を行っている際に、
CHANGE MASTER TOで、 MASTER_LOG_POSを指定せずに実行し、slaveを起動したところ、次のようならエラーが出ていました。
Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000011' at 218, the last event read from './mysql-bin.000011' at 4, the last byte read from './mysql-bin.000011' at 4.'
このエラーはちゃんとmasterのpositionを指定し直した解消されました。
またもう一つ、slave stopせずにCHANGE MASTER TOを実行したら、
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000011', MASTER_LOG_POS=107;
ERROR 1198 (HY000): This operation cannot be performed with a running slave; run STOP SLAVE first
というエラーも出てしました:(;゙゚'ω゚'):
CHANGE MASTER TOはslave stopを実行してからやりましょうね( ̄ー+ ̄)キラリってことですね!

他のやり方として、
http://server-setting.info/centos/mysql_replication_1236_error.html
1062のエラー対処でも、スキップさせる方法を紹介していましたが、
エラーを無視するだけなら、
my.conf ( [mysqld]セクション )に
slave-skip-errors = 1236
を追記して、MySQLをリスタートすれば、すべての1236エラーは無視されます。
ただ、これは、原因がマスター側にある場合が多いので、スキップせずにちゃんと確認した方が良いです。当たり前ですけど。。。
というやり方もあるそうです(`・ω・´)ゞビシッ!!


参考URL

2012年11月11日日曜日

データベースが消せない!(ERROR 1010 (HY000): Error dropping database )

データベースを消そうとしたら、次のようなエラーが発生してしまい消せませんでした(; ・`д・´)
mysql> DROP DATABASE データベース名;
ERROR 1010 (HY000): Error dropping database (can't rmdir './データベース名', errno: 39)
仕方ないので強引に/var/lib/mysql/データベース名/のディレクトリを
全部mvで退避させてから実行してみると問題なくSHOW DATABASES一覧から消えました!ワーイヽ(゚∀゚)メ(゚∀゚)メ(゚∀゚)ノワーイ
こんなやり方でも消せるんですね(´・∀・`)ヘー

というか、エラー内容にcan't rmdirって書かれてるという事は、
MySQLもDROP TABLEを実行すると単純にディレクトリをごっそり消してるだけだったり・・・?o(゚Д゚ = ゚Д゚)o キョロキョロ


参考URL

リストアの高速化

データの復旧時やslaveの追加時のセットアップ用にdumpファイルをリストアする際に
なるべく時間をかけずにやれる方法です!m9( ゚Д゚) ドーン!

リストアの性能を上げるために次の項目を一時的に無効化します。
・一般クエリログの無効化
・バイナリーログの無効化
・Double Writeの無効化
・コミット時のディスクフラッシュの無効化

vi /etc/my.cnf
#ダブルライトバッファの無効化
skip_innodb_doublewrite
#slaveでバイナリーログを出力している場合には設定をコメントアウトして無効化にする
#log_slave_updates

# /etc/init.d/mysqld restart
Stopping mysqld:                                           [  OK  ]
Starting mysqld:                                           [  OK  ]
■一般ログの無効化
mysql> SHOW GLOBAL VARIABLES LIKE '%general_log%';
+------------------+---------------------------+
| Variable_name    | Value                     |
+------------------+---------------------------+
| general_log      | ON                        |
| general_log_file | /data/mysql-log/mysql.log |
+------------------+---------------------------+
2 rows in set (0.02 sec)

mysql> SELECT @@general_log;
+---------------+
| @@general_log |
+---------------+
|             1 |
+---------------+
1 row in set (0.01 sec)

#general_logを0にする(再起動するとmy.cnfの値に戻る)
mysql> SET GLOBAL general_log = 0;
Query OK, 0 rows affected (0.06 sec)

mysql> SELECT @@general_log;
+---------------+
| @@general_log |
+---------------+
|             0 |
+---------------+
1 row in set (0.00 sec)
■バイナリーログの無効化
mysql> SHOW GLOBAL VARIABLES LIKE '%log_bin%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| log_bin                         | ON    |
| log_bin_trust_function_creators | OFF   |
| sql_log_bin                     | ON    |
+---------------------------------+-------+
3 rows in set (0.00 sec)

#sql_log_binを0にする(再起動するとmy.cnfの値に戻る)
mysql> SET GLOBAL sql_log_bin = 0;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%log_bin%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| log_bin                         | ON    |
| log_bin_trust_function_creators | OFF   |
| sql_log_bin                     | OFF   |
+---------------------------------+-------+
3 rows in set (0.00 sec)
■コミットと同時にログファイルの内容をディスクへフラッシュを無効化
mysql> SELECT @@innodb_flush_log_at_trx_commit;
+----------------------------------+
| @@innodb_flush_log_at_trx_commit |
+----------------------------------+
|                                1 |
+----------------------------------+
1 row in set (0.00 sec)

#innodb_flush_log_at_trx_commitを2にする(再起動するとmy.cnfの値に戻る)
mysql> SET GLOBAL innodb_flush_log_at_trx_commit = 2;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @@innodb_flush_log_at_trx_commit;
+----------------------------------+
| @@innodb_flush_log_at_trx_commit |
+----------------------------------+
|                                2 |
+----------------------------------+
1 row in set (0.00 sec)
ダンプファイルが大きい場合には次のようなエラーが出る場合があります。
$ mysql -u root -p --default-character-set=utf8 データベース名 < /home/admin/データベース名.2012-11-04_18-00-01.sql
Enter password:
ERROR 2006 (HY000) at line 7944: MySQL server has gone away
その場合には、次の設定値を大きくしてから試してみてください。
#起動中のまま32MBに設定を変更する場合(再起動するとmy.cnfの値に戻る)
mysql> SET GLOBAL max_allowed_packe=32*1024*1024;

#my.cnfの設定で行う場合
#[mysqld]セクションのmax_allowed_packetのサイズを大きくする。
max_allowed_packet = 32M

リストアが終わったら各項目を元に戻すこと。
クラッシュ時にデータが破損してしまう可能性が高い設定になってしまっているため

他にも高速化の方法として、ログファイルサイズの調整、自動拡張の抑制、パーティショニング、
更新のサイズ、CSVストレージエンジンの活用などを行うと高速化することができるそうです。
下記参考URLから確認してみてください!(`・ω・´)ゞビシッ!!

参考URL

テーブルスペース初期化で大きいサイズ指定の際の注意点

テーブルスペースの初期化は大きめに取っておいた方が
自動拡張の回数が減るからI/Oが発生しにくくなってパフォーマンスが(・∀・)イイ!!

と、前の記事やどこかの記事でみたので試してみた際のφ(`д´)メモメモ...
■テーブルスペースを30Gで初期化した場合について

あまり大きいサイズを指定すると、
起動した際にテーブルスペースの初期化で時間がかかってしまって、
MySQLが起動に失敗したように見えるらしいです。

たとえば次の設定を行って起動してみると、
#
innodb_data_file_path = ibdata1:30G:autoextend

# /etc/init.d/mysqld start
MySQL Daemon failed to start.
Starting mysqld:                                           [FAILED]
起動できない!!どうしようどうしよう!って慌ててプロセスを見てみると、
# ps axu|grep -i [m]ysql
root     11810  0.1  0.0 106108  1496 pts/1    S    00:37   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql    12691  0.6  4.4 5057200 363608 pts/1  Sl   00:37   0:01 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/data/mysql-log/mysql-error.log --open-files-limit=8192 --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --port=3306
プロセスが残っていて起動している事に・・・ついにMySQLの霊的な何かががががっ:(;゛゜'ω゜'):

ではなくて、MySQLさんがバックグラウンドで何か頑張っている模様ですガン( ゜д゜)ガレ
ただログインを試してみるけどエラーにはなる。
# mysql -u root
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
ibdataを見てみると設定したサイズより小さいファイルが作られているけど、
時間が経過すると少しずつ大きくなっている。

# ls -alt /var/lib/mysql/|grep ibdata
-rw-rw---- 1 mysql mysql 1258291200 Nov 10 21:43 ibdata1
# ls -alt /var/lib/mysql/|grep ibdata
-rw-rw---- 1 mysql mysql 2306867200 Nov 10 21:47 ibdata1
# ls -alt /var/lib/mysql/|grep ibdata
-rw-rw---- 1 mysql mysql 2831155200 Nov 10 21:48 ibdata1
# ls -alt /var/lib/mysql/|grep ibdata
-rw-rw---- 1 mysql mysql 4194304000 Nov 10 21:52 ibdata1
# ls -alt /var/lib/mysql/|grep ibdata
-rw-rw---- 1 mysql mysql 5567471616 Nov 10 21:57 ibdata
このまま待っていると、設定したサイズになり完了して、ログインも行えるようになります。
ただ、待っている時間が・・・なんと約2時間ほどかかりました:(;゛゜'ω゜'):
長すぎて寝てしまうところでした(つд⊂)ゴシゴシ

その時のMySQLのログはこちらになります。
121110 20:33:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
121110 20:33:33 [Note] Plugin 'FEDERATED' is disabled.
121110 20:33:33 [ERROR] Function 'rpl_semi_sync_master' already exists
121110 20:33:33 [Warning] Couldn't load plugin named 'rpl_semi_sync_master' with soname 'semisync_master.so'.
121110 20:33:33 InnoDB: The InnoDB memory heap is disabled
121110 20:33:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
121110 20:33:33 InnoDB: Compressed tables use zlib 1.2.3
121110 20:33:33 InnoDB: Using Linux native AIO
121110 20:33:33 InnoDB: Initializing buffer pool, size = 4.0G
121110 20:33:34 InnoDB: Completed initialization of buffer pool
121110 20:33:34 InnoDB: highest supported file format is Barracuda.
"/data/mysql-log/mysql-error.log" [readonly] 509L, 33378C
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
121111  0:37:20  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 256 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: 127 rollback segment(s) active.
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
121111  0:40:04  InnoDB: Waiting for the background threads to start
121111  0:40:05 InnoDB: 1.1.8 started; log sequence number 0
121111  0:40:05 [Note] Semi-sync replication initialized for transactions.
121111  0:40:05 [Note] Semi-sync replication enabled on the master.
121111  0:40:06 [Warning] 'user' entry 'root@db03' ignored in --skip-name-resolve mode.
121111  0:40:06 [Warning] 'user' entry '@db03' ignored in --skip-name-resolve mode.
121111  0:40:06 [Warning] 'proxies_priv' entry '@ root@db03' ignored in --skip-name-resolve mode.
121111  0:40:06 [Note] Event Scheduler: Loaded 0 events
121111  0:40:06 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.22-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi
起動時にエラーが起きないようにするには、起動スクリプトのSTARTUPTIMEOUTの値を変更すれば良いかも?
view /etc/init.d/mysqld

# Set timeouts here so they can be overridden from /etc/sysconfig/mysqld
STARTTIMEOUT=120
STOPTIMEOUT=60
MYOPTIONS=
(`・ω・´)ゞビシッ!!

テーブルスペース肥大化の対処方法(ibdata*)

前回テーブルスペースについて調べてみた後に、
運用中のサーバーの設定をやファイルを確認してみたら・・・innodb_file_per_tableが使われていない!!!:(;゙゚'ω゚'):

という事なので、早速設定の方を試してみましたワッショイヽ(゚∀゚)メ(゚∀゚)メ(゚∀゚)ノワッショイ

■手順1.現状のibdata1のサイズの確認をしてみる
# ls -alt /var/lib/mysql/|grep ib
-rw-rw----  1 mysql mysql 277899902976 11月 10 16:16 2012 ibdata1
-rw-rw----  1 mysql mysql      5242880  4月 16 15:06 2012 ib_logfile0
-rw-rw----  1 mysql mysql      5242880  4月  6 12:05 2012 ib_logfile1

277899902976・・・(;゜ Д゜) …!?
277,899,902,976byteっていくつでしたっけ?もちろん277MBですよね?(;゚ Д゚) …!?

チガイマスネ。277GBですね・・・orz

とりあえず、my.cnfにinnodb_file_per_tableだけを追加してやってみた結果。
#設定前のサイズ
# ls -alt /var/lib/mysql/|grep ib
-rw-rw----  1 mysql mysql 277899902976 Nov 10 21:08 ibdata1
-rw-rw----  1 mysql mysql      5242880 Apr 16  2012 ib_logfile0
-rw-rw----  1 mysql mysql      5242880 Apr  6  2012 ib_logfile1
設定直後には/var/lib/mysq/データベース名/に*.ibdファイルが作られていないが、
ALTER TABLE テーブル名 ENGINE InnoDB;

のコマンドを実行すると、ibdファイルが作成される。
# ls -alt /var/lib/mysql/データベース名/|grep ibd
-rw-rw----  1 mysql mysql     163840 Nov 10 20:19 user.ibd
こちらから引用です。
ALTER TABLE 実行中もテーブルからREADが出来るからだ。
テーブルが壊れた場合にはREPAIR TABLEコマンドを使うし、最適化したい場合にはOPTIMIZE TABLEコマンドを使うのだが、
これらのコマンドはWRITEだけでなくREADもブロックしてしまう。従って、メンテナンス中にWRITEは出来なくてもREADだけは可能にしたい、
というような場合には、まずはALTER TABLEを試して見るといいだろう。

ALTER TABLEは操作が正常に完了するまでは元のテーブルに対して一切の変更を加えない。
たとえコマンド実行中にマシンがクラッシュしても、テンポラリテーブルの残骸が残るだけで、元のテーブルは元通りである。 そういう意味では、ALTER TABLEはとても安全な操作であるとも言える。
innodb_file_per_table設定後に作られたこのファイルは
ALTERコマンドを利用するとデフラグを行ってくれるため、
定期的に実行することで*.ibdのサイズは小さくなる。(ibdata1のサイズは変わらない)
# ls -alt /var/lib/mysql/
total 271977488
-rw-rw----  1 mysql mysql 277899902976 Nov 10 22:14 ibdata1
なので、元々あったibdataのサイズは変わらない・・・ガ━━(;゚Д゚)━━ン!!

そこで、ibdata1のサイズを小さくしたい場合には、
ibdata1のサイズを変更した場合には元々あったibdataやib_logfile0を一度消す必要がある。

消すという事は、全データを消すことになるので、
復元する為にデータベースをダンプし、リストアを行う必要があるみたいです。

単純に、my.cnfの設定で、値を変えた場合のエラーは次のような内容でした。
#デフォルトの設定(自動拡張有効で、初期化で10MBの領域を確保する)
innodb_data_file_path = ibdata1:10M:autoextend
↓
#自動拡張有効で、初期化で30Gの領域を確保する
#innodb_data_file_path = ibdata1:30G:autoextend

#エラー内容
121110 21:03:24 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
121110 21:03:24 [Note] Plugin 'FEDERATED' is disabled.
121110 21:03:24 [ERROR] Function 'rpl_semi_sync_master' already exists
121110 21:03:24 [Warning] Couldn't load plugin named 'rpl_semi_sync_master' with soname 'semisync_master.so'.
121110 21:03:24 InnoDB: The InnoDB memory heap is disabled
121110 21:03:24 InnoDB: Mutexes and rw_locks use GCC atomic builtins
121110 21:03:24 InnoDB: Compressed tables use zlib 1.2.3
121110 21:03:24 InnoDB: Using Linux native AIO
121110 21:03:24 InnoDB: Initializing buffer pool, size = 4.0G
121110 21:03:24 InnoDB: Completed initialization of buffer pool
InnoDB: Error: auto-extending data file ./ibdata1 is of a different size
InnoDB: 1152 pages (rounded down to MB) than specified in the .cnf file:
InnoDB: initial 1966080 pages, max 0 (relevant if non-zero) pages!
121110 21:03:24 InnoDB: Could not open or create data files.
121110 21:03:24 InnoDB: If you tried to add new data files, and it failed here,
121110 21:03:24 InnoDB: you should now edit innodb_data_file_path in my.cnf back
121110 21:03:24 InnoDB: to what it was, and remove the new ibdata files InnoDB created
121110 21:03:24 InnoDB: in this failed attempt. InnoDB only wrote those files full of
121110 21:03:24 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
121110 21:03:24 InnoDB: remove old data files which contain your precious data!
121110 21:03:24 [ERROR] Plugin 'InnoDB' init function returned error.
121110 21:03:24 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
121110 21:03:24 [Note] Semi-sync replication initialized for transactions.
121110 21:03:24 [Note] Semi-sync replication enabled on the master.
121110 21:03:24 [ERROR] Unknown/unsupported storage engine: InnoDB
121110 21:03:24 [ERROR] Aborting

121110 21:03:24 [Note] unregister_replicator OK
121110 21:03:24 [Note] /usr/libexec/mysqld: Shutdown complete

121110 21:03:24 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

それでは、本題のibdataをリセットしてみます(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

今回は、レプリケーションを既に行っているmaster,slave環境で、
ibdataをリセットしたかったので、レプリケーションの設定を再度やり直す方法にしました。

■手順1.念のためmasterの更新系の処理をロックする(参照系はロックされない)
# FLUSH TABLES WITH READ LOCK;
■手順2.masterのロックとテーブルスペースへの反映が正常に完了しているか確認
こちらから引用。
Log sequence numberは、ログバッファへの更新が行われたトータルのバイト数、
Log flushed up toはWALへの書き込みが行われたバイト数、
Last checkpoint atは最後にチェックポイントが行われたバイト数
innodb_flush_log_at_trx_commit=1ならば、Log sequence numberとLog flushed up toは非常に近い値になる。
ログからテーブルスペースへ書き込み中の可能性もあるので確認する
SHOW ENGINE INNODB STATUSの"Log sequence number"と"Log flushed up to"の値が同じであることを確認する。
#5.5より前のバージョンはSHOW INNODB STATUS\G
SHOW ENGINE INNODB STATUS\G
---
LOG
---
Log sequence number 694320234293
Log flushed up to   694320234293
Last checkpoint at  694320234293
0 pending log writes, 0 pending chkp writes
11390094 log i/o's done, 0.00 log i/o's/second
mysql> show status LIKE '%Key_blocks_not_flushed%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| Key_blocks_not_flushed | 0     |
+------------------------+-------+
1 row in set (0.00 sec)
値が一致しない場合、または念のために、
ログファイル内のデータを全てテーブルスペースへ反映させる方法でシャットダウンしておいた方が良いかも?
#
mysql> SELECT @@global.innodb_fast_shutdown;
+-------------------------------+
| @@global.innodb_fast_shutdown |
+-------------------------------+
|                             1 |
+-------------------------------+
1 row in set (0.00 sec)

#ログファイル内のデータを全てテーブルスペースへ反映させてからシャットダウンする設定に変更
mysql> SET GLOBAL innodb_fast_shutdown=0;

#停止
/etc/init.d/mysqld stop

#起動
/etc/init.d/mysqld start
■手順3.masterサーバーのデータをダンプする
--all-database 全てのデータベースのからデータをdumpする --master-data=2をつけておく。
slaveのセットアップで利用できるバイナリーログのファイル名と開始位置を出力する。 --default-character-set=binary
--single-transaction
InnoDBを利用している場合、テーブルへの参照&更新をブロックすることなく、
mysqldumpコマンド開始時点のスナップショットを取る。(MyISAMなどでは利用できない)
--flush-logs
バイナリーログのローテーションを行う
--quick
#全てのデータベースをダンプする場合
# mysqldump -u root -p --all-database --master-data=2 --default-character-set=binary --single-transaction --flush-logs --quick | gzip --best -c > /data/tmp/all_database_20121111.sql.gz
■手順4.データベースの削除 ダンプでフルバックアップを取ってあるので、DROP DATABASEで全部消しておいた方が良いかも。
消す場合には、mysqlがデフォルトで作成するデータベースは残しておく。
(information_schema、performance、mysql、test)

DROP DATABASEをせずに、手順9のibdata*,ib_logfile*をmvまたはrmでした場合に、
全データは無くなるが、データベースのディレクトリが残ってしまい、リストアがうまく行かない場合がある。 各データベースのdatabaseのディレクトリが残ってしまっている。(*.ibdが残っていた)

そのせいかリストアした際に、次のようなエラーが出てしまった。
ERROR 1005 (HY000) at line 39: Can't create table 'データベース名.access_log' (errno: 1)
テーブルがあるせいなのかと思い、SHOW TABLEで確認してみるけど、
全て消えてしまって無くなっていました。

SHOW DATABASESでは名前があったのでDROP DATABASEを試してみるけど、 次のようなエラーが発生で消せませんでした。
mysql> DROP DATABASE データベース名;
ERROR 1010 (HY000): Error dropping database (can't rmdir './データベース名', errno: 39)
仕方ないので強引に/var/lib/mysql/データベース名/のディレクトリを
全部mvで退避させてから実行してみると問題なくリストアが進みました!(`・ω・´)シャキーン ■手順5.masterの更新系のロック解除とMySQLの停止
mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)

# /etc/init.d/mysqld stop
Stopping mysqld:                                           [  OK  ]
■手順6.slave側のテーブルスペースへの反映の確認
#5.5より前のバージョンはSHOW INNODB STATUS\G
SHOW ENGINE INNODB STATUS\G
---
LOG
---
Log sequence number 672811663077
Log flushed up to   672811663077
Last checkpoint at  672811663077
0 pending log writes, 0 pending chkp writes
9667 log i/o's done, 0.00 log i/o's/second

mysql> show status LIKE '%Key_blocks_not_flushed%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| Key_blocks_not_flushed | 0     |
+------------------------+-------+
1 row in set (0.05 sec)
masterと同様に値が一致しない場合には、手順2の方法でSET GLOBAL innodb_fast_shutdown=0;を利用する。
■手順7.slaveの停止
slaveの停止
mysql> slave stop;
Query OK, 0 rows affected, 1 warning (0.00 sec)

# /etc/init.d/mysqld stop
Stopping mysqld:                                           [  OK  ]
■手順8.master側のmy.cnfの設定を変更
# vi /etc/my.cnf

#デフォルト値
innodb_data_file_path = ibdata1:10M:autoextend
#拡張時に64MBの領域を確保する
innodb_autoextend_increment=64
#テーブルスペースをテーブル単位で作成する
innodb_file_per_table
■手順9.ibdata*,ib_logfile*を退避させる
# mv /var/lib/mysql/ibdata* /tmp/
# mv /var/lib/mysql/ib_logfile* /tmp/
※innodb_log_group_home_dirを設定している場合には、ib_logfileはその場所にあります。
デフォルトではdatadirで設定した場所になります(datadirのデフォルト設定は/var/lib/mysql/)
■手順10.MySQLを起動させる
# /etc/init.d/mysqld start
Starting mysqld:                                           [  OK  ]
■手順11.ibdataが初期化された確認する
# ls -alt /var/lib/mysql/
total 2286160
drwxr-xr-x 11 mysql mysql      12288 Nov 11 12:43 .
-rw-rw----  1 mysql mysql  268435456 Nov 11 12:43 ib_logfile0
-rw-rw----  1 mysql mysql   77594624 Nov 11 12:43 ibdata1
-rw-rw----  1 mysql mysql  268435456 Nov 11 12:43 ib_logfile1
77594624ということは、77,594,624byte。77MBになった(゚∀゚)キタコレ!!
無事に277GBが77MBのダイエットに成功!!これはダイエット本として発売するしかっ(ΦωΦ)フフフ…
■手順12.各テーブルごとに作られる.ibdファイルが作られているか確認する
# ls -alt /var/lib/mysql/データベース名/|grep ibd
total 1988
drwxr-xr-x 11 mysql mysql 12288 Nov 11 12:43 ..
この時点では.ibdファイルは作られていないΣ(゚Д゚ υ) アリャ ※ibdataなどを初期化したのでデータが全部消えてしまっている。 ■手順13.先程ダンプしたファイルをリストアする。
#先程ダンプしたファイルの解凍
# gunzip /data/tmp/all_database_20121111.sql.gz

#リストア
# mysql -u root --default-character-set=utf8 < /data/tmp/all_database_20121111.sql
■手順14.再度*.ibdファイルがあるか確認してみる
# ls -alt /var/lib/mysql/データベース名/|grep ibd
-rw-rw----  1 mysql mysql 3317694464 Nov 11 13:14 *****.ibd
-rw-rw----  1 mysql mysql  234881024 Nov 11 13:14 *****.ibd
-rw-rw----  1 mysql mysql   58720256 Nov 11 13:07 *****.ibd
-rw-rw----  1 mysql mysql     196608 Nov 11 13:06 *****.ibd

キタ――(゚∀゚)――!!
これで、無事にibdataのリセットに成功しました(`・ω・´)シャキーン
後は、定期的にALTER TABLEを行うことでデフラグを解消してくれて、
ibdファイルのサイズは小さくしてくれます。
■手順15.slave側のibdataのリセット。
手順6でslaveの停止をしているので、手順7以降を同様にslaveでも行う。

■手順16.レプリケーションの開始設定
slaveのibdataなどを削除したため、
再度レプリケーションの設定が必要となります。
手順12で利用したダンプファイルからmasterの情報を利用して、 slaveの設定を行います。
#
head -100 /data/tmp/all_database_20121111.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000028', MASTER_LOG_POS=107;
上記のコマンドで出力されたLOG_FILEとLOG_POSの値を、
CHANGE MASTER TOのMASTER_LOG_FILE、MASTER_LOG_POSの各値に設定する。
#レプリケーションの設定
mysql> CHANGE MASTER TO
    -> MASTER_HOST='masterサーバーのIPアドレス',
    -> MASTER_USER='slaveユーザーのアカウント名',
    -> MASTER_PASSWORD='slaveユーザーのパスワード',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='mysql-bin.000028',
    -> MASTER_LOG_POS=107,
    -> MASTER_CONNECT_RETRY=10;
Query OK, 0 rows affected (0.02 sec)

#同期開始
mysql> SLAVE START;
以上(`・ω・´)ゞビシッ!!
ibdataにあったものが個々のテーブルの*.ibdファイルに分散され、ibdataは小さくなりましたが、
運用を続けているとibdataはやっぱり肥大化してしまうみたいです。
(ibdataファイルにはデータは入らなくなったけど、各*.ibdのメタデータを保存してるため)
ただ、今回の設定をしておくことで、その肥大化の速度を緩やかにすることが出来る!
と言ったことなのかな?
設定の注意点としては、
innodb_file_per_tableを設定してもibdataは必要なので消してはいけません!
innodb_log_group_home_dirを設定してはいけません!!
ド━━━━m9(゚∀゚)━━━━ン!!

参考URL

2012年11月10日土曜日

テーブルスペースとログファイルについて(ibdata*、ib_logfile*)

いつもmysqlの中身を見た時に巨大化しているファイルを良く見かけていましたが、
( ´_ゝ`)フーンっていうぐらいにしか思っていなかったので
ibdata*とib_logfile*について調べてみました(ΦωΦ)フフフ…

簡単な説明をすると、
ibdata*は共有テーブルスペース(全データを管理します。)
ib_logfile*は、ログファイルらしいです。

データは直接テーブルスペースに更新がされるのではなく、
一旦ログファイルに更新内容が書き込まれる。
その後に、テーブルスペースに反映される流れになっているらしい。
テーブルスペースの更新はコストが高いのですぐに反映するのではなく、
ログファイルに書いておくことで、書き込みの性能をあげてるらしい(´・∀・`)ヘー

そのため、InnoDBのデータは、テーブルスペースとログを合わせて完全な情報となるらしい。

↓実際のファイルはこいつらですド━━━━m9(゚∀゚)━━━━ン!!
# ls -alt /var/lib/mysql
合計 14871500
-rw-rw----  1 mysql mysql    5242880 11月  5 01:49 2012 ib_logfile0
-rw-rw----  1 mysql mysql    5242880 11月  5 01:49 2012 ib_logfile1
-rw-rw----  1 mysql mysql 9590276096 11月  5 01:49 2012 ibdata1
それでは、まずはibdataの詳細について!(`・ω・´)シャキーン

ibdataはデフォルトの設定では、全データを1つのファイルで管理している?ので、
運用を続けていくうちにどんどん肥大化していきます。

その原因として、デフォルトの設定のibdataファイルの自動拡張設定があります。
自動拡張の設定は、innodb_data_file_pathでautoextendが記述されていると拡張されてしまう。
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
この設定があると、最大値が無いためHDD100%まで肥大化してします・・・:(;゙゚'ω゚'):

また一度大きくなったibdataのテーブルスペースを小さくする手段としては、
ダンプ後にibdata*のファイルを削除後にリストアするしか方法がないとのことですガ━━(;゜Д゜)━━ン!!

自動拡張が原因なので、自動拡張の上限をつければ良いかと思いきや、
今度は上限に達した場合に、テーブルへの更新が出来なくなるという現象になるらしい・・・orz
HDDの100%になっても出来ませんけどね・・・その際にはMySQLにすらログインできなくなる(´;ω;`)ウッ…

自動拡張無しの設定
[mysqld]
innodb_data_file_path=ibdata1:300G
自動拡張を無くした状態で、テーブルスペースを大きくしたい場合には、
[mysqld]
innodb_data_file_path=ibdata1:300G;/data2/ibdata2:700G
のように記述していかなければいけない。
(ibdata1とibdata2というファイルが作られる?)

そこで、この問題を回避するための手段として、innodb_file_per_tableを設定する方法がある(゚∀゚)キタコレ!!
ただし注意点として次のようなことがあるそうです。
こちらのサイトから引用です
innodb_file_per_tableの設定をしておくと、テーブルごとにテーブルスペースが作成される
拡張子は.ibdである。.ibdファイルは要求に応じて自動拡張するのだが、テーブルを削除すると対応する.ibdファイルも削除されるのである。
つまり、一度テーブルスペースが大きくなってしまってからでもテーブルを削除すればファイルシステムの空き領域を増やすことが可能になるのである。
これは運用上とてもメリットがあるだろう。
テーブルごとにテーブルスペースを作成する場合でも、共有テーブルスペース(ibdata1)が必要になる点に注意しよう。
ここには、各テーブルのディクショナリ情報や ロールバックセグメントなどが格納される。一度に大量のアップデートを行った場合などには大きなロールバックセグメントが必要になる。
その際に共有テーブルスペースが自動拡張しないよう、サイズを決めうちにしておくといいだろう。

ただし、この運用で気をつけないといけないのは共有テーブルスペースを削除してはならない!!ということである。
確かに共有テーブルスペースにテーブルのデータは入っていないが、各.ibdのメタデータを格納しているので、
共有テーブルスペースがないとInnoDBが.ibdファイルを見つけられないのである。
また、他のサーバへ単体の.ibdファイルだけを持っていっても使えない。(無理矢理使う方法はあるけど一般的にはオススメしない。)
つまり、.ibdファイルと共有テーブルスペースはセットなのである。

innodb_file_per_tableを設定しても、ibdataは消しちゃダメ!絶対!ァカンァカン(´゚д゚`)ノ゙ノ゙ってことですね!
あとは、innodb_data_home_dirを明示的に指定する場合には、
innodb_file_per_tableオプションは利用してはいけないらしい。

■データファイルの初期化について
利用するディスク容量が決まっている場合には、最初にデータファイルを初期化しておくと良い。
データファイルは自動拡張しますが、拡張するタイミングでI/Oが発生するため、
最初に領域を確保し自動拡張しないように設定した方が高速になる。
#2TB用の設定
innodb_data_file_path=ibdata1:2000G
データファイルのサイズが大きい場合には初期化の時間にかかってしまうので、
セットアップを早く終わらせた場合には、次のように記述する。
#自動拡張を有効にして、最大値が500G、拡張子時に確保するサイズは64MBになる。
innodb_data_file_path=ibdata1:1G:autoextend:max:500G
innodb_autoextend_increment=64
maxを設定しない場合には、肥大化に気をつけてHDDのサイズを超えないようにする。

実際のテーブルスペースの肥大化の対象方法いついてはこちらの記事に書いてあります(`・ω・´)ゞビシッ!!


参考URL

2012年11月4日日曜日

ウェブ監視(特定のURLの監視方法)

zabbixにはウェブ監視と呼ばれるものがあります。
指定したURLに対して定期的にアクセスを行い、そのレスポンスや速度を計測してくれます(・∀・)イイ!!

早速、設定の方を行ってみたいと思います。
■手順1.上部メニューの「設定」→「ウェブ」をクリックすると、ウェブ監視一覧が表示されます。

■手順2.右上にホストで、ウェブ監視を行いたいホストをプルダウンで選び、「シナリオの作成」を押すと、
シナリオの新規作成画面が表示されます。

■手順3.シナリオの設定画面で次のように入力する。
アプリケーション:WebMonitoring
名前:web01 server
認証:Basic認証(Basic認証を利用しているページにアクセスする場合には指定する)
ユーザ:(Basic認証を利用している場合にはIDを入力する)
パスワード:(Basic認証を利用している場合にはパスワードを入力する)
更新間隔(秒):30
エージェント:その他を選択して「zabbix_web_monitoring」を入力する
ステータス;有効
変数:{test}=test
【アプリケーション】
アイテムのグループ化用の名前になります。
【認証、ユーザ、パスワード】
認証ページなどを監視する場合に必要となる認証方法、ユーザ、パスワードになります。
【エージェント】
zabbixサーバーが監視用にアクセスする際のユーザーエージェントになります。
google analyticsなどで解析を行っている場合に、ウェブ監視のアクセスという事を
分かりやすくする為に、一応ユーザーエージェントを一般的なもの以外にしてあります。
ただ、google analyticsとかapacheのログならならzabbix serverのIPアドレスを除外リストに入れておけば問題ないかな?:(;゙゚'ω゚'):
【ステータス】
監視を行うかの状態になります。
【変数】
zabbixサーバーがアクセスを行う際に送信するデータの変数の登録。(変数の登録のみで送信データの登録ではない)
複数URLの監視を行う際や、送信データを共通で利用したい場合に設定しておくと管理が楽になる。
送信データがベタ書きでかまわない場合には、特に設定の必要なし。 たとえば、ページにアクセスする際にid値として10000を送りたい場合には、
ここで{id}の変数の値を{id}=1000と登録しておき、ステップの登録画面でid={id}として設定することで
送信することが出来ます。
{変数名}=値の記述方法になります。複数の場合には改行区切りになります。

■手順4.ステップの追加を押すと、ステップの登録画面が表示されるので、各項目を入力して、追加を押します。


名前:index.php
URL:http://test.com/index.php
POST:未記入
タイムアウト:15
要求文字列:未記入
ステータスコード:200
【名前】
アクセスするページの識別名。
【URL】
アクセスするページのURL
【POST】
アクセスする際にPOSTする値
【タイムアウト】
レスポンスを待つ時間
要求文字列は、レスポンス結果に特定の文字列が含まれているかどうかをチェックするための、判定文字列の登録。設定しない場合にはチェック無し。
【ステータスコード】
レスポンス結果の期待するステータスコードの設定。
複数ある場合にはカンマ区切りで入力する(200,201 or 200,201,200-211 )
※監視したいページが複数ある場合には、数分だけステップを追加してください。

POST送信したい場合には、POSTの項目に
id={id}&password={password}のように登録ができる。

GET送信したい場合には、URLの欄にhttp://test.com/index.php?id={id}&password={password}のように登録することでGET送信が可能です。 ※シナリオの登録画面の変数で{変数名}の変数が登録されている場合には変数が使えます。
登録していない場合にはベタ書きで設定すればその値が送信されます。
■手順5.ステップの登録が完了したら、シナリオの設定画面の保存を押して反映させる。

以上になります(`・ω・´)ゞビシッ!!

確認方法は、「監視データ」→「ウェブ」の一覧から先程設定した情報を追加されていると思います。

2012年10月31日水曜日

レプリケーション設定(非同期レプリケーション)

レプリケーションの設定を行いたいと思います。
master用と、slave用のMySQLが既にインストール済みの状態から説明したいと思います。
MySQLのインストールについてはこちらを参考にしてください
(準同期レプリケーションについては、この記事の設定が終わった後にこちらを参考にしてください)

■手順1.masterの設定を変更します。
[mysqld]セクションに次の項目を追加する。
# vi /etc/my.cnf
#バイナリーログを有効化
log-bin=mysql-bin
#レプリケーション方式の選択SBRとRBRを動的に切り替える(デフォルトはMIXED)
binlog_format=MIXED
#バイナリーログファイルのサイズ
max_binlog_size=100M
#バイナリーログの有効期限
expire_logs_days=3
#1回バイナリログへ更新を行うことでディスクへのフラッシュを行う
sync_binlog=1
#InnoDBのログバッファをInnoDBログファイルに書き込むタイミングを決める
innodb_support_xa=1
#2相コミットを行うかどうか。ログをコミットごとにフラッシュしない
innodb_flush_log_at_trx_commit=1
#テーブルスペースをテーブル単位で作成する
innodb_file_per_table

MySQLレプリケーションを安全に利用するための10のテクニックからの引用になります。
5. バイナリログを同期する 適切な設定をしておかないと、サーバがクラッシュしてしまった場合などに最後にバイナリログに対して行った更新が失われてしまう場合がある。バイナリログの一部が失われてしまうと、スレーブへ更新内容を転送することが出来なくなる。そのため、マスターとスレーブでデータの食い違いが生じるので、レプリケーションは停止する。このような状況になった場合、最悪はマスターからデータのコピーをやり直す必要があるので厄介だ。そのような状況になりたくない場合には、次の設定をしておこう。 sync_binlog=1
innodb_support_xa=1
innodb_flush_logs_at_trx_commit=1

レプリケーション時のデータの整合性やクラッシュ時の事を考えるなら、上記の三つは必須項目で、
パフォーマンスを考えると場合によっては変えた方が(・∀・)イイ!!って感じかな?

my.cnf編集後に再起動を行う。
# /etc/init.d/mysqld restart
mysqld を停止中:                                           [  OK  ]
mysqld を起動中:                                           [  OK  ]
MySQLにログインして確認する
mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       126 |
| mysql-bin.000002 |       126 |
| mysql-bin.000003 |       126 |
| mysql-bin.000004 |       126 |
| mysql-bin.000005 |       126 |
| mysql-bin.000006 |       126 |
| mysql-bin.000007 |       126 |
| mysql-bin.000008 |       107 |
+------------------+-----------+
8 rows in set (0.01 sec)
mysql> show master status\G
*************************** 1. row ***************************
            File: mysql-bin.000008
        Position: 107
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
■手順2.マスター上にレプリケーション用のユーザーを作成する。
スレーブが複数ある場合にはホスト名にワイルドカードを用いて、
すべてのホストからログインできる統一のレプリケーション用アカウントを作成するか、
スレーブのホストごとにユーザーを作成する必要がある。
マスターの現在のユーザーを確認する
mysql> SELECT user, host, password FROM mysql.user;
+------+-----------+----------+
| user | host      | password |
+------+-----------+----------+
| root | localhost |          |
| root | 127.0.0.1 |          |
| root | ::1       |          |
+------+-----------+----------+
3 rows in set (0.08 sec)
slaveがmasterのデータベースに接続するためslaveユーザーを作成する。
今回はslaveで共通のアカウントを利用する方法を利用しますので、
一番上のコマンドでユーザーを作成します。
#slaveごとに共通のアカウントを利用する場合、 
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%' IDENTIFIED BY '任意のパスワード';

#slaveごとにアカウントを分ける場合 
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'slaveのIPアドレス' IDENTIFIED BY '任意のパスワード';

#指定IPアドレスのネットワーク内なら全て許可(IPアドレス/255.255.255.0) 
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@'指定のIPアドレス/255.255.255.0' IDENTIFIED BY '任意のパスワード';
slaveユーザー作成。
#slaveユーザー作成
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%' IDENTIFIED BY '*****';
Query OK, 0 rows affected (0.08 sec)

#権限の確認
mysql> SHOW GRANTS FOR 'slave'@'%';
+--------------------------------------------------------------------------------------------------------------------------------------+
| Grants for slave@%                                                                                                                   |
+--------------------------------------------------------------------------------------------------------------------------------------+
| GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%' IDENTIFIED BY PASSWORD '*2222CF6639797EFE06ED82985752723FE6BB0BA0' |
+--------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

#設定の反映
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
間違った権限や、情報でユーザーを作ってしまった場合には、次の手順で削除を行う。
#間違ったアカウントを作った場合には権限を全て取り上げてから削除すること全ての権限を取り上げる
mysql> REVOKE ALL ON *.* FROM 'slave'@'%';
Query OK, 0 rows affected (0.02 sec)

#権限がなくなっているか確認
mysql> SHOW GRANTS FOR 'slave'@'%';
+------------------------------------------------------------------------------------------------------+
| Grants for slave@%                                                                                   |
+------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'slave'@'%' IDENTIFIED BY PASSWORD '*2222CF6639797EFE06ED82985752723FE6BB0BA0' |
+------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

#slaveユーザー削除
mysql> DELETE FROM mysql.user WHERE USER LIKE 'slave' AND HOST LIKE '%';
Query OK, 1 row affected (0.06 sec)

#slaveユーザーが削除されているか確認
mysql> SELECT user, host, password FROM mysql.user;
+------+-----------+----------+
| user | host      | password |
+------+-----------+----------+
| root | localhost |          |
| root | 127.0.0.1 |          |
| root | ::1       |          |
+------+-----------+----------+
3 rows in set (0.00 sec)

#反映
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
■手順3.レプリケーションのテスト用にデータベース、テーブル、レコードの作成を行う。
#データベースの作成
mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.01 sec)

#テーブルを選択
mysql> use test;
Database changed

#テーブルの作成
mysql> CREATE TABLE IF NOT EXISTS `user` (
    ->   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    ->   PRIMARY KEY (`id`)
    -> ) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.09 sec)

#レコードの登録
mysql> INSERT INTO user( id ) VALUES( 1 );
Query OK, 1 row affected (0.03 sec)

#データの確認
mysql> SELECT * FROM user;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.00 sec)
■手順4.slaveのセットアップ用データとしてmasterのデータをdumpする。
# mysqldump -u root -p --all-databases --master-data=2 --single-transaction --flush-logs > /home/admin/dump_20121031_01.sql
Enter password:

#dumpファイルの確認
# ls -alt /home/admin/dump_20121031_01.sql
-rw-r--r-- 1 root root 513573 11月  1 01:03 2012 /home/admin/dump_20121031_01.sql
mysqldumpの各オプションの説明
・--all-databases
全てのデータベースからデータをdumpします。
・--master-data=2
slaveのセットアップで利用できるバイナリログのファイル名と開始位置を出力する。
・--single-transaction
利用しているストレージエンジンがInnoDBだけの場合、
このオプションを付けるだけでテーブルへの参照や更新をブロックすることなく、
コマンド開始時点のデータのスナップショットを採取することができます。
この指定が無い場合には、mysqldumpで全てのテーブルをREADロックしてしまう。
・--flush-logs
バイナリログのローテーションを行います。

■手順5.dumpファイルをslaveに転送する。
ポート番号を変更してるので-Pオプションがついてます。
#転送コマンド
scp /home/admin/dump_20121031_01.sql ユーザー名@slaveのIPアドレス:/tmp/

■手順6.手順2で作成したユーザーがslaveからログインできるかチェック。

共通のアカウント用のコマンドでslaveユーザーを作成した場合には、IPアドレスの制限などが無いので、
slaveとなるサーバーであればどのサーバーからでもログインが出来るようになっている。
slaveサーバーに移動した後に、次のコマンドを実行してみる。
# mysql -h masterのIPアドレス -u slave -p
Enter password:パスワード入力
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 231
Server version: 5.5.27-log MySQL Community Server (GPL) by Remi

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
次のようなエラーメッセージが出る場合には、設定がうまく行えていない可能性があります。
ERROR 1130 (HY000): Host 'slaveのIPアドレスorホスト名' is not allowed to connect to this MySQL server

■手順7.slaveのmy.cnf設定

スレーブ用にmy.cnfを編集します。 [mysqld]セクションに次の項目を追加します。
vi /etc/my.cnf
#
server-id=20
#masterでSHOW SLAVE HOSTSコマンドを実行したときにスレーブの一覧が見れるように。
report_host=slave20
#書き込み禁止(SUPER権限のユーザーは書き込めてしまう)
read_only=1
#slaveの自動同期開始を無効化
skip_slave_start
#ログ関係はデフォルトだとホスト名が使われてしまうので指定しておいたほうが、
#後の管理が楽になるので指定しておく方が良いかも?
#バイナリーログのファイル名の指定。(slaveをmasterに昇格する場合など用に必要な場合のみ)
log_bin=mysql-bin
#バイナリーログを生成する場合にはこの記述も忘れずに!
#この指定がないとslave側では正しくバイナリーログが生成されない。
log_slave_updates
#リレーログのファイル名(masterから取得したバイナリーログを別名で保存したもの)
relay_log=mysql-relay-bin
#リレーログのインデックス用?のファイル名
relay-log-index==mysql-relay-bin
#テーブルスペースをテーブル単位で作成する
innodb_file_per_table

■手順8.slaveの起動を行い、リストアを行う。 slaveの同期を停止させている状態で起動する。
# /etc/init.d/mysqld start
mysqld を起動中:                                           [  OK  ]

既に一度slaveの設定がされていたり、余計なデータベースなどがある場合には削除する。
デフォルトで作られるデータベースの、
information_schema、performance_schema、mysql、testは消さない

・information_schema
INFORMATION_SCHEMAデータベースはMySQLに存在するデータベースやテーブルなどの情報を
参照するために利用できるものです

・performance_schema
実行性能に関する統計情報など?

・mysql
mysqlはアカウントユーザー情報が入っている。上書きされる。
・test
テスト用のデータベース?テーブルは無しの状態っぽい。

information_schemaデータベースは削除できないっぽい?
mysql> DROP DATABASE information_schema;
ERROR 1044 (42000): Access denied for user 'root'@'localhost' to database 'information_schema'
余計なデータベースを削除したらdumpファイルをリストアする。
mysql -u root -p --default-character-set=utf8 < /tmp/dump_20121031_01.sql
リストアしたデータが正常に登録されているか確認する。
# mysql -u root
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.02 sec)

#
mysql> use test;
Database changed

#
mysql> SELECT * FROM user;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.00 sec)
■手順9.dumpファイルからレプリケーションの設定を情報を取得し、設定する。
次のコマンドでdumpファイルからレプリケーションの設定情報を取得する
# head -100 /tmp/dump_20121031_01.sql | grep CHANGE
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=107;
上記のコマンドで出力されたLOG_FILEとLOG_POSの値を、CHANGE MASTER TOのMASTER_LOG_FILE、MASTER_LOG_POSの各値に設定する。
#レプリケーションの設定
mysql> CHANGE MASTER TO
     MASTER_HOST='masterサーバーのIPアドレス',
     MASTER_USER='slaveユーザーのアカウント名',
     MASTER_PASSWORD='slaveユーザーのパスワード',
     MASTER_PORT=3306,
     MASTER_LOG_FILE='mysql-bin.000009',
     MASTER_LOG_POS=107,
     MASTER_CONNECT_RETRY=10;
Query OK, 0 rows affected (0.02 sec)
■手順10.slave起動 CHANGE MASTER TOコマンドだけではslaveの同期が開始されません
Slave_IO_Running、Slave_SQL_RunningがNoになっていると思います
#slaveのステータスを確認する
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: *************
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 107
               Relay_Log_File: mysql-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: No
            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: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 107
              Relay_Log_Space: 107
              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: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 0
1 row in set (0.00 sec)

#slave起動
mysql> START SLAVE;
Query OK, 0 rows affected (0.02 sec)

#再度、ステータスを確認する。Slave_IO_Running、Slave_SQL_RunningがYesになっている事を確認する
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: ************
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 107
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 107
              Relay_Log_Space: 409
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 10
1 row in set (0.00 sec)

#system userというプロセスがslaveが利用しているプロセスになりますのでkillなどで殺してはいけない。
mysql> SHOW PROCESSLIST;
+-----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+
| Id  | User        | Host      | db   | Command | Time | State                                                                       | Info             |
+-----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+
| 327 | root        | localhost | NULL | Query   |    0 | NULL                                                                        | SHOW PROCESSLIST |
| 333 | system user |           | NULL | Connect |   22 | Waiting for master to send event                                            | NULL             |
| 334 | system user |           | NULL | Connect |   22 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL             |
+-----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)
■手順10.masterにデータを登録して同期されるか確認してみる
#masterサーバーでデータの登録する
mysql> INSERT INTO user( id ) VALUES( 2 );
Query OK, 1 row affected (0.01 sec)
mysql> SELECT * FROM user;
+----+
| id |
+----+
|  1 |
|  2 |
+----+
2 rows in set (0.00 sec)
slaveサーバーでに接続して同期されているか確認する
#slaveサーバーでデータの確認をする
mysql> SELECT * FROM user;
+----+
| id |
+----+
|  1 |
|  2 |
+----+
2 rows in set (0.00 sec)
以上でレプリケーションの設定は完了です(`・ω・´)ゞビシッ!! 今回利用したmater,slaveの設定ファイルはこちらになります。
master側のmy.cnf
# Example MySQL config file for large systems.
#
# This is for a large system with memory = 512M where the system runs mainly
# MySQL.
#
# MySQL programs look for option files in a set of
# locations which depend on the deployment platform.
# You can copy this option file to one of those
# locations. For information about these locations, see:
# http://dev.mysql.com/doc/mysql/en/option-files.html
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
#password       = your_password
port            = 3306
socket          = /var/lib/mysql/mysql.sock

#文字コードをUTF-8
default-character-set=utf8

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-external-locking
key_buffer_size = 256M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

#文字コードをUTF-8
character-set-server=utf8

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking

# Replication Master Server (default)
# binary logging is required for replication
#バイナリーログを有効化
log-bin=mysql-bin

#エラーログを有効化
log-error = mysql-error.log

#バイナリーログの有効期限
expire_logs_days=31

#1回バイナリログへ更新を行うことでディスクへのフラッシュを行う
sync_binlog=1

#InnoDBのログバッファをInnoDBログファイルに書き込むタイミングを決める
innodb_support_xa=1

#2相コミットを行うかどうか。ログをコミットごとにフラッシュしない
innodb_flush_log_at_trx_commit=1

# binary logging format - mixed recommended
binlog_format=mixed

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
#サーバーの識別ID(ユニークな値にする)
server-id       = 10

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
#    the syntax is:
#
#    CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
#    MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
#    where you replace <host>, <user>, <password> by quoted strings and
#    <port> by the master's port number (3306 by default).
#
#    Example:
#
#    CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
#    MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
#    start replication for the first time (even unsuccessfully, for example
#    if you mistyped the password in master-password and the slave fails to
#    connect), the slave will create a master.info file, and any later
#    change in this file to the variables' values below will be ignored and
#    overridden by the content of the master.info file, unless you shutdown
#    the slave server, delete master.info and restart the slaver server.
#    For that reason, you may want to leave the lines below untouched
#    (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id       = 2
#
# The replication master for this slave - required
#master-host     =   <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user     =   <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password =   <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port     =  <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 256M
#innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 64M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

#DNS逆引きを無効化
skip-name-resolve

#簡単な目安としてサーバーに積んであるメモリの50%~80%を指定するの(・∀・)イイ!!らしいです。
innodb_buffer_pool_size = 256M

#ログファイルのバッファサイズ
innodb_log_buffer_size = 16M

#ログファイルのサイズ
innodb_log_file_size = 128M

#ログファイルを作成する数
innodb_log_files_in_group = 2

#デフォルトのままで。(自動拡張有効で、初期化で10MBの領域を確保する)
innodb_data_file_path = ibdata1:10M:autoextend

#拡張時に64MBの領域を確保する
innodb_autoextend_increment=64

#ibdataの肥大化対策用にテーブルスペースをテーブル単位で作成する
#(innodb_file_per_tableを利用する場合にはinnodb_log_group_home_dirは設定してはいけない)
innodb_file_per_table

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

#文字コードをUTF-8
default-character-set=utf8

[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

slave側のmy.cnf
# Example MySQL config file for large systems.
#
# This is for a large system with memory = 512M where the system runs mainly
# MySQL.
#
# MySQL programs look for option files in a set of
# locations which depend on the deployment platform.
# You can copy this option file to one of those
# locations. For information about these locations, see:
# http://dev.mysql.com/doc/mysql/en/option-files.html
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
#password       = your_password
port            = 3306
socket          = /var/lib/mysql/mysql.sock

#文字コードをUTF-8
default-character-set=utf8

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-external-locking
key_buffer_size = 256M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

#文字コードをUTF-8
character-set-server=utf8

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking

# Replication Master Server (default)
# binary logging is required for replication
#バイナリーログを有効化
log-bin=mysql-bin

#エラーログを有効化
log-error = mysql-error.log

#バイナリーログの有効期限
expire_logs_days=31

#1回バイナリログへ更新を行うことでディスクへのフラッシュを行う
sync_binlog=1

#InnoDBのログバッファをInnoDBログファイルに書き込むタイミングを決める
innodb_support_xa=1

#InnoDBのログバッファをInnoDBログファイルに書き込むタイミングと、
#InnoDBログファイルをディスクにフラッシュするタイミングの設定
innodb_flush_log_at_trx_commit=1

# binary logging format - mixed recommended
binlog_format=mixed

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
#サーバーの識別ID(ユニークな値にする)
server-id       = 20

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
#    the syntax is:
#
#    CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
#    MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
#    where you replace <host>, <user>, <password> by quoted strings and
#    <port> by the master's port number (3306 by default).
#
#    Example:
#
#    CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
#    MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
#    start replication for the first time (even unsuccessfully, for example
#    if you mistyped the password in master-password and the slave fails to
#    connect), the slave will create a master.info file, and any later
#    change in this file to the variables' values below will be ignored and
#    overridden by the content of the master.info file, unless you shutdown
#    the slave server, delete master.info and restart the slaver server.
#    For that reason, you may want to leave the lines below untouched
#    (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id       = 2
#
# The replication master for this slave - required
#master-host     =   <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user     =   <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password =   <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port     =  <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 256M
#innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 64M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

#DNS逆引きを無効化
skip-name-resolve

#簡単な目安としてサーバーに積んであるメモリの50%~80%を指定するの(・∀・)イイ!!らしいです。
innodb_buffer_pool_size = 256M

#ログファイルのバッファサイズ
innodb_log_buffer_size = 16M

#ログファイルのサイズ
innodb_log_file_size = 128M

#ログファイルを作成する数
innodb_log_files_in_group = 2

#デフォルトのままで。(自動拡張有効で、初期化で10MBの領域を確保する)
innodb_data_file_path = ibdata1:10M:autoextend

#拡張時に64MBの領域を確保する
innodb_autoextend_increment=64

#ibdataの肥大化対策用にテーブルスペースをテーブル単位で作成する
#(innodb_file_per_tableを利用する場合にはinnodb_log_group_home_dirは設定してはいけない)
innodb_file_per_table

###########
# slave用の設定
###########
#masterでSHOW SLAVE HOSTSコマンドを実行したときにスレーブの一覧が見れるように。
report_host=slave20

#書き込み禁止(SUPER権限のユーザーは書き込めてしまう)
read_only=1

#slaveの自動同期開始を無効化
skip_slave_start

#バイナリーログを生成する場合にはこの記述も忘れずに!
#この指定がないとslave側では正しくバイナリーログが生成されない。
#ただし、マスターの予備用として出力しておくのはダメ。
#log_slave_updates

#リレーログのファイル名(masterから取得したバイナリーログを別名で保存したもの)
relay-log=mysql-relay-bin

#リレーログのインデックス用?のファイル名
relay-log-index==mysql-relay-bin

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

#文字コードをUTF-8
default-character-set=utf8

[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

zabbix_agentの設定(zabbixサーバー側のホスト設定)

前回の記事で、監視対象のサーバー側の設定は完了しましたが、
zabbixのWebインターフェースで見えるようにするには、こちら側の設定も必要になります。
zabbixにログインしたら次の手順で設定を行います。

1.「設定」→「ホスト」でホスト一覧を表示する。
2.右の方に「ホストの作成」を押すと、新規作成画面が表示される。
3.ホストの設定で、各項目を次のように入力する。


・名前には、ホスト一覧で表示される名前になりますので、分かりやすい名前をつける。
・グループには、既に存在するグループと同じものがあれば、その他のグループから選択して、「<<」を押してグループに追加します。
・新規のグループとして追加したい場合には、新規ホストグループにグループ名を入力します。
・IPアドレスには、監視対象サーバーのIPアドレスを入力します。
・リンクしているテンプレートの枠の追加を押すと、ポップアップが表示されるので、その中から追加するテンプレートを追加する。
 今回はとりあえず、Webサーバーの監視なので、Template_App_httpdと、Template_OS_Linuxを設定しておきます。
 (テンプレートが表示されていない場合には、右上のプルダウンから「全て」を選択すると出てくるかもしれません)
 Template_App_httpdが見当たらない方は、テンプレートが追加されていない可能性があるので、
 こちらの記事を参考に追加してみてください。

今回は次のように入力しました。

4.保存を押して、設定を保存して、ホスト一覧で設定したい内容が追加されているか確認する。
 (ステータスが有効になっていることと、エージェントの状態が緑色になっていれば正常に動作しています)

以上です(`・ω・´)ゞビシッ!!