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