mysql主从复制的一些东西的整理

最近给新上线的项目进行主从结构的搭建，因此整理些有用的东西出来，供作记录：

一.mysql主从复制的一般配置步骤：

　　1.准备两台数据库环境，或者单台多实例的环境，能够正常的启动和登陆。

　　2.配置my.cnf文件，主库配置log-bin和server-id参数，从库配置server-id参数，不能和主库及其他从库一样，一般不开启从库的log-bin功能。注意：参数配

　　　置后要重启才能生效。

　　3.登陆主库增加用于从库连接主库同步的账户例如：rep，并授权replication slave同步的权限。

　　4.登陆主库，并进行整库锁表 flush table with read lock (窗口关闭后即失效，超时参数到了也失效)；然后show master status查看binlog的位置状态。

　　5.新开窗口，linux命令行备份或者导出原有的数据库数据，并拷贝到从库所在的服务器上。

　　6.解锁主库，unlock tables；

　　7.把主库导出的原有数据恢复到从库。

　　8.根据主库的show master status查看binlog的位置状态，在从库下面执行change master to..的语句。

　　9.从库开启同步开关，start slave.

　　10.从库show master status \G查看同步的状态

二.复制主线程的状态：

　　下面列出了主服务器的Binlog Dump线程的State列的最常见的状态。如果你没有在主服务器上看见任何的Binlog Dump线程，这说明复制没有在运行，目前没有连接任何从服务器。

1.sending binlog event to slave  ----- 线程已经从二进制日志读取了一个事件并且正将它发送到从服务器。

　　2.finished reading one binlog;switch to next binlog --- 线程已经读完二进制日志并且正打开下一个要发送到从服务器的日志文件。

　　3.Has sent all binlog to slave;waiting for binglog to be updated -- 线程已经从二进制日志读取所有主要的更新并已经发送到了从服务器。线程现在正空闲，等待由主服务器上新的更新导致出现在二进制日志中的新事件。

4.waiting to finalize termination -- 线程停止时发生的一个很简单的状态。

三.复制从I/O线程状态：

　　使用  show slave status 显示State的最新状态，常见的状态如下：

　　1.connecting to master --- 线程正试图连接主服务器

　　2.checking master version -- 建立同主服务器之间的连接 后出现的短暂的状态。

　　3. requesting binlog dump　

四. (1).生产授权方案1：

　　主库：web  oldboy123 10.0.0.1 3306 （select insert delete update）

　　从库：主库的web用户同步到从库，然后回收insert delete,update的权限

　　不收回从库的权限，设置read-only参数去报从库只读。（注释：read-only参数只允许来自root或者super权限的账号的连接，对与普通用户则不会生效）　　

　　对开发而言：

　　主库：web  oldboy123 10.0.0.1 3306 （select insert delete update）

　　从库：web  oldboy123 10.0.0.2 3306 （select）

　　(2).生产授权方案：

　　主库：web_w  oldboy123 10.0.0.1 3306 （select insert delete update）

　　从库：web_r  oldboy123 10.0.0.2 3306 （select）

　　风险：web_w连接从库！ 对开发而言，多套用户密码不专业。

　　(3).生产授权方案3：

　　mysql库不同步，即不同步授权的mysql库：

　　使用：replicate-ignore-db=mysql; binlog-ignore-db=mysql即可不用同步授权的账号

　　然后对主从库进行如下的授权：

　　主库：web  oldboy123 10.0.0.1 3306 （select insert delete update）

　　从库：web  oldboy123 10.0.0.2 3306 （select）

　　缺陷：当从库换成主库的时候，发生问题

　　方案：保留一个从库专门接替主库即可

　　replication中还可以通过一下的选项来减少binlog的数据量，来达到提升效率的目的，前两个用在Master端，后六个用在Slave端

　　Master端：

　　--binlog-do-db:二进制日志记录的数据库（多个数据库用，分隔）

　　--binlog-ignore-db:二进制日志记录的忽略的数据库（多个数据库用，分隔）

　　Slave端：

　　--replication-do-db:设定需要复制的数据库（多个数据库用，分隔）

　　--replication-ignore-db:设定忽略复制的数据库（多个数据库用，分隔）

　　--replication-do-table:设定需要复制的表（多个表用，分隔）

　　--replication-ignore-table:设定需要忽略的复制的表（多个表用，分隔）

　　binlog_format="MIXED"   #设置bin-log日志文件格式为：MIXED，可以防止主键重复。

五.mysql的主从复制的应用场景：

　　mysql主从复制有利于数据库结构的健壮性，提升访问速度和易于维护管理。

　　1).主从服务器互为备份

　　　　主从服务器架构的设计，可以大大的加强数据库架构的健壮性。例如：当主服务器出现问题的时候，我们可以人工或者自动的切换到从服务器继续提供服务。

　　　　这个类似于之前nfs存储数据通过inotify+rsync同步到备份的nfs非常的类似，只不过MySQL的同步方案，是其自带的工具。

　　2).主从服务器读写分离分担网站的压力：

　　　　主从服务器的架构可通过程序（php，java）或者代理软件（mysql-proxy，amoeba）对用户的请求实现读写分离，即通过在从服务器上仅仅处理select查

　　　　询的请求，降低用户的查询时间以及读写同时在主服务器上带来的压力，对于更新的数据（update insert delete）仍然交给主服务器处理，确保主服务器

　　　　和从服务器保持实时的同步，如果网站是以非更新为主的业务，如blog，www的首页展示等业务，查询的请求比较多，这是从服务器的读写分离负载均衡策

　　　　略就很有效了，这就是读写分离数据结构。

　　　　中大型公司：通过程序（php，java）

　　　　测试环境：代理软件（mysql-proxpy，amoeba）

　　　　门户网站：分布式dbproxy（读写分离，hash负载均衡，健康检查）。

　　　　下面是一个常用的mysql的架构：