mysql主库不可用切换备库为主库，再重建备库的几种思路

  这次主要讨论的场景是主库A突然不可用，切换了备库B为主库，并且备库B已经开始正常跑业务成为了主库，现在是要在原主库A上建立备库。

  这里不分析主库不可用的原因，只分为重启后能启动的情况可mysql是正常的且里面数据也正常的情况和mysql是不正常的情况。

      先简单的普及一下主从复制原理：

          mysql每次的变更数据（由于主从复制行为发生的更改默认不计入binlog）都会记录在binlog日志中，binlog日志的记录模式有三种，本次主要是以row模式为主。

          先使用命令查看一下binlog：

           登陆mysql后执行

           show binary logs  查看目前在册的binlog日志;

如图所示，binglog文件的标志号是按顺序生成的，主从复制，读完一个binlog就会读下一个。

           show binlog events in 'mysql_bin_30001.000004' ;  简要的查看binlog文档内容

图中可看到pos这个参数是binglog的日志标记号他是不断增加且不重复的，主从复制就是通过这个pos位置的推进一个个事件进行同步，比如其中的update_row的事件，就是表示有更新语句，完整解析binglog日志命令：

mysqlbinlog -vv --base64-output=decode-rows /data/kdcc_data/mysql/mysql3336/log/mysql_bin_30001.000004

会看到有一条update语句如下

   如图所见他不会记录我们原来发出的语句而是跟新后和跟新前的全部列，这样有利于回滚某个误操作数据 或是查找修改前的数据。

   show master status；当前数据库写入数据的binglog以及写到binglog的哪一个配置。只要有变更数据库里面的数据这个position就会变大，如果binglog文件的大小达到设定值就会转到新增的binlog文件。

我们也可以使用flush logs，让他主动的从新的文件开始写。这个操作不会产生任何影响可放心食用；

•  情况1：原主库A重启后能启动的情况是：mysql是正常的且里面数据也正常的情况；

           思路1（切换前就做好准备功夫）：主库发生故障必须要切备库时，备库肯定不会有任何写入，先在备库上执行命令  flush logs。让他另起一个新的日志文件开始写。然后再切到备库这样情况的好处是我们能够很清楚的查到这个新主库是从新的binlog文件的第一个位置开始写入，接下来如果能恢复原主库就能够使用change maseter 命令指定新的master开始复制的binlog及他的位置。一般情况有可能会发生主键冲突，只需要跳过几个主键冲突的错误（3个以内，若太多了还是使用情况2的做法）。

           思路2（切换前没准备）：由于不知道确切的位置，可以根据我上面分析binlog的几个操作，查到对应的binlog位置，具体做法是先根据binlog文件的修改时间和实际发生切换的大致时间，就可以判断出是哪个binlog文件。然后再使用解析binlog文件的命令解析binlog，查看里面的时间就能找到