16.1、主库"show master status"没有结果：
1、原因：
主库binlog功能开关没有改或没有生效；
2、解决办法：
（1）[root@backup ~]#egrep "server-id|log-bin" /data/3306/my.cnf
log-bin = /data/3306/mysql-bin
server-id = 1
（2）mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
1 row in set (0.00 sec)
mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+
1 row in set (0.00 sec)
（3）提示：
配置文件my.cnf中的参数和show variables里的参数不一样；
my.cnf配置文件中的是log-bin，show variables中的是log_bin;
16.2、CHANGE MASTER时多了空格：
1、错误：
mysql > show slave stauts\G;
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'
2、解决办法：
重新CHANGE MASTER;
或找到最近的没有数据的pos点重新chang master;
16.3、使用mysql启动时显示已经启动了，但是mysql没有启动：
1、原因：
mysql 没有正常关闭导致的问题：
2、解决办法
删除mysql的mysql.pid和mysql.sock文件
rm -f /data/3306/mysql.sock /data/3306/*.pid
16.4、由于切换binlog导致show master status 位置变化无影响；
16.5、mysql_InnoDB独立表空间物理文件被误删的解决方法：
1、因为InnoDB格式的表索引都保存在ibdata1这个文件中，虽然物理文件*.ibd,*.frm被删除，但是ibdata1中的索引没有删除，所以
数据库认为该表已经存在，导致创建失败。
2、解决方案是： 比如test表的.frm文件误删了首先新建一个文件名字叫test.frm(cp -a other.frm test.frm)，然后使用drop命令
删除该数据库drop table test，删除之后会发现该数据库的物理文件夹中还存在test.ibd文件；
删除该文件 然后再次建表就ok了；
16.6、mysql从库数据冲突导致同步停止的解决方案：
1、报错：
2、解决方法：
（1）方法一：
stop slave;
set global sql_slave_skip_counter = 1;
start slave;
提示：sql_slave_skip_counter=n #n取值大于0，忽略执行n个更新；
对于普通的互联网业务，忽略问题不是很大，当然在不影响公司业务的前提下；
企业场景解决主从同步，比主从不一致当前更重要，主从同步数据一致很重要，需
要中找个时间恢复下这个从库；
缺点：容易造成数据丢失；
（2）方法二：
根据错误号跳过指定的错误：
slave-skip-errors = 1032,1062,1007 #一般由于入库重复导致的失败问题就可以进行忽略；
提示：你也可以使用不推荐的all值忽略所有的错误消息，不考虑所发生的错误。如果使用改制，
我们不能保证数据的完整性。
（3）其他可能引起同步的问题：
1）mysql自身的原因；
2）不同的数据库版本会引起不同步，低版本到高版本可以，但是高版本不能往低版本同步；
3）mysql的错误；
16.7、主库master宕机的解决方案：
1、登陆各个从服务器分别查看master.info文件；
cat /data/3307/data/master.info
cat /data/3308/data/master.info
18
mysql-bin.000035 #mysql-bin文件
331 #pos点
172.16.1.41
lc
123456
3306
60
0
0
1800.000
0
选择mysql-bin文件和pos值最大的点作为主库；
2、确保选择从库的relay_log全部都更新完毕：
stop slave io_thread;
show processlist\G;
直到看到sql线程已经是：Has read all relay log; waiting for the slave I/O thread to update it为止；
表示从库更新都执行完成；
提示：如果主库还能够启动，需要把主库的binlog日志拉到选定的主库并导入；
3、把选定的从库切换成主库：
stop slave;
reset master;
quit;
4、进到选定从库目录，删除master-info和relay-log.info文件：
cd /data/3307/data
rm -f master.info relay-log.*
5、提升选择的从库为主库：
vim /data/3306/my.cnf
开启：log-bin = /data/3307/mysql-bin
#如果存在log-slave-updates,read-only等一定要注释掉；
/data/3307/mysql restart
授权同步的用户和主库一致；
到此为止主库提升完毕；
6、分别登陆其他的从库：
stop slave;
change master to master_host = '172.168.1.41'; #如果不同步需要获取master的为止点并指定；
start slave；
show slave status\G; #查看状态，从库切换成功；
补充：
CHANGE MASTER TO
MASTER_HOST='172.16.1.41',
MASTER_PORT=3306,
MASTER_USER='lc',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=331;
7、修理损坏的主库，完成后作为从库进行使用；
8、如果是有计划的主从库切换的做法为：
（1）主库锁表；
flush table with read lock;
unlock tables;
（2）登陆所有的库查看同步状态，是否同步完成；
（3）然后按照前面的3-7步骤完成操作；
16.8、从库slave宕机的解决方案：
从做slave：
stop slave；
gzip -d /tmp/mysql_bal.sql.gz #该文件是前天凌晨备份好的，库是inoodb引擎，使用
了--mstart-data=1参数备份的库；
mysql -uroot -p123456 -S /data/3306/mysql.sock
CHANGE MASTER TO
MASTER_HOST='172.16.1.41',
MASTER_PORT=3306,
MASTER_USER='lc',
MASTER_PASSWORD='123456';
start slave;
show slave status\G;
16.9、binglog查看时报错：
[root@db01 data]# mysqlbinlog mysql-bin.000013
mysqlbinlog: unknown variable 'default-character-set=utf8'
#出现这种情况的原因是my.cnf中[client] default-character-set=utf8,解决的办法是，去掉此参数,在
#在/etc/sysconfig/i18n中设置zh_CN.UTF8即可解决乱码的问题，而这种方法不会影响mysql客户端
#和库的编码一致性；