当主库发生宕机，从库如何接管主库
1、主库崩溃，日志不在情况（会丢数据）
查看从库已经同步到哪了，①确定数据丢失的时间范围，②确定从库的中继日志是否被SQL_thread进程解析完（即传输过来的中断日志是否在从库上重放完）。
1.1、如何确定数据丢失的时间范围
登录从库服务器，进入mysql数据库,执行以下命令，查看相关的参数：
mysql> show slave status\G
Master_Log_File 表示IO thread读取到的binlog日志文件名
Read_Master_Log_Pos IOthread读取到的binlog日志文件位置
Relay_Log_File slave 在本地缓存的relay 日志的文件名
Relay_Log_Pos slave 在本地缓存的relay 日志的文件位置
Relay_Master_Log_File SQL thread执行到master的binlog文件名
Exec_Master_Log_Pos SQL thread 执行到master的binlog文件位置
Seconds_Behind_Master SQL thread相对master的延迟时间（该值理论上显示了备库的延时，但由于各种各样的原因，并不总是准确的）
1）通过Master_Log_File 与Read_Master_Log_Pos可查看到从库服务器拉取主库服务器日志的文件名与位置。（从库 IO thread进程所做的事）
2）通过Relay_Log_File与Relay_Los_Pos两个值可以得到从库在本地缓存的中继日志文件名与文件位置。
3）通过Relay_Master_Log_File与Exec_Master_Log_Pos可以得到从库重放binlog到主库的哪个日志文件哪个位置。（从库 SQL thread进程所做的事）
1.1.1、查看从库同步的位置：
方法一：通过Master_Log_File 与Read_Master_Log_Pos可以确定从库只同步到主库的哪个日志文件哪个位置上。
方法二：查看master.info
1.1.2、查看从库同步的时间：
如果想要知道具体时间，可以查看中继日志
[[email protected]]# pwd
/var/lib/mysql
[[email protected]]# mysqlbinlog relay-bin.000005
查看内容如下：
1.2、确定从库的中继日志是否被sql_thread进程解析完
比较Master_Log_File与Relay_Master_Log_File是否相同，比较Read_Master_Log_Pos与Exec_Master_Log_Pos是否相同，如果两者都相同，那么代表解析完，如果有任何一个不一样，要等待sql_thread解析完。
1.3、如果从库之前有配置只读不写操作，还要作相关修改，操作请看下面的第4点。
2、主库崩溃，日志还在情况
关闭从库的io_thread，在主库上插入几条数据，（来模拟主库宕机，日志没有完全同步到从库的情况）。
从库操作：
mysql>stop slave io_thread;
QueryOK, 0 rows affected (0.06 sec)
主库操作，在apex_db库下插入以下数据：
mysql>insertinto apex_tb values(100,‘apexdb‘);
QueryOK, 1 row affected (0.10 sec)
mysql>insert into apex_tb values(101,‘apexdb‘);
QueryOK, 1 row affected (0.00 sec)
mysql>insert into apex_tb values(111,‘apexdb‘);
QueryOK, 1 row affected (0.06 sec)
mysql>insert into apex_tb values(121,‘apexdb‘);
QueryOK, 1 row affected (0.06 sec)
mysql>insert into apex_tb values(131,‘apexdb‘);
QueryOK, 1 row affected (0.06 sec)
2.1、如何判断从库是否与宕机的主库同步了
2.1.1、查看主库的最新日志，通过mysqlbinlog查看
# cd /var/lib/mysql
# mysqlbinlog master-bin.000003
内容如下：
可以看出主库的最新日志文件名是master-bin.000003，位置是2679。
2.1.2、登录从库，查看同步的位置
登录从库服务器，进入mysql数据库,执行以下命令，查看相关的参数：
mysql> show slave status\G
从以上参数可以看出，从库不同步。
2.1.3、登录主库，把主库的日志（master-bin.000003、master-bin.000004、……）传送给从库
# scpmaster-bin.000003 192.168.1.133:/tmp/
2.2、同步的情况，如果从库被设置为只读不写操作，要作相应的修改。
具体操作请看下面的第4点。
2.3、不同步的情况，从库操作
cd /tmp
mysqlbinlog--start-position=1530 master-bin.000003 > a.sql
mysql -uroot -papex_db <a.sql
登录数据库查看数据是否同步。
2.4、如果从库之前有配置只读不写操作，还要作相关修改，操作请看下面的第4点。
3、主库存活，从库怎么切换
3.1、查看主从库是否同步
3.1.1主库操作，查看写入日志的位置
3.1.2从库操作，查看从库同步的位置
从3.1.1与3.1.2数据可以看成主库的日志都已经传输到从库。
3.1.3、主库设置为只读操作
flush tableswith read lock;
3.1.4、断开主从库之间复制进程（IO_thread）
从库设置：
mysql>stopslave io_thread;
3.1.5、确定从库的中继日志是否被sql_thread进程解析完
比较Master_Log_File与Relay_Master_Log_File是否相同，比较Read_Master_Log_Pos与Exec_Master_Log_Pos是否相同，如果两者都相同，那么代表解析完，如果有任何一个不一样，要等待sql_thread解析完。
3.2、如果从库之前有配置只读不写操作，还要作相关修改，操作请看下面的第4点。
4、如果之前从库是只读不写操作，要进行以下操作：
4.1、使用set命令修改read_only参数的值，并修改从库的配置文件my.cnf,把read_only参数修改为read_only=0参数，实现不管是否有没有重启mysql服务，都能实现从库接管主库，对外提供读写操作。
4.1.1、临时修改法，实现不重启数据库，从库能提供读写
mysql>set global read_only=0;
4.1.2、修改配置文件read_only值为0,实现重启数据库，从库也能提供读写
#vi /usr/my.cnf
read_only=0
#service mysql restart
使用4.1.1与4.1.2实现不管是否有没有重启mysql服务，都能实现从库接管主库，对外提供读写操作。
4.2、授权，给从库授于update,delete,insert权限
#mysql –uroot –p
#grantupdate,delete,insert on *.* to [email protected]’%’ identified by ‘123456’;
#flushprivileges;