原理:
MySQL的主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个MySQL数据库（我们称之为Master）复制到另
一个MySQL数据库（我们称之为Slave），在Master与Slave之间实现整个主从复制的过程是由三个线程参与完成的。其中有两个线程
（SQL线程和I/O线程）在Slave端，另外一个线程（I/O线程）在Master端。
要实现MySQL的主从复制，首先必须打开Master端的binlog记录功能，否则就无法实现。因为整个复制过程实际上就是Slave从Master端
获取binlog日志，然后再在Slave上以相同顺序执行获取的binlog日志中所记录的各种SQL操作。
要打开MySQL的binlog记录功能，可通
过在MySQL的配置文件my.cnf中的mysqld模块（[mysqld]标识后的参数部分）
增加“log-bin”参数选项来实现，具体信息如下。
[mysqld]
log-bin = /data/3306/mysql-bin
[图片]
提示：有些把log-bin放在了配置文件结尾，而不是[mysqld]标识后，从而导致配置复制不成功。
主库安装步骤:
yum install mysql mysql-server mysql-devel
/etc/init.d/mysqld start 启动mysql
chkconfig mysqld on #设为开机启动
vi /etc/my.cnf
[mysqld]下增加
server-id=1 ##id不能重复
log-bin=/data/mysql-bin
重新启动mysql （如果无法启动 检查/data/目录权限和mysql-bin权限，还是不行关闭selinux）
// 给数据库设置密码
进入数据库 mysql -u root -p
show variables like 'server_id'; 查看是否有值 配置文件设置的值
show variables like 'log_bin'; 是否启用 是否为ON
show variables like '%timeout%';
wait_timeout -- 指的是MySQL在关闭一个非交互的连接之前所要等待的秒数
interactive_time -- 指的是mysql在关闭一个交互的连接之前所要等待的秒数(交互连接如mysql gui tool中的连接)
建立一个从库的访问用户 db 用phpmyadmin或者其他工具建立
show master status; 命令显示的信息要记录在案，后面的从库导入全备后，继续和主库复制时就是要从这个位置开始。
从库
/vi /etc/my.cnf
[mysqld]
server-id=2
read-only #只读
进入数据库 mysql -u root -p
执行:
CHANGE MASTER TO
MASTER_HOST='192.168.10.167',
MASTER_PORT=3306,
MASTER_USER='db',
MASTER_PASSWORD='111111',
MASTER_LOG_FILE='mysql-bin <==log-bin.000001',
MASTER_LOG_POS=0;
查看show slave status; 下面3个参数正常
Slave_IO_Running：Yes
Slave_SQL_Running:Yes
Seconds_Behind_Master是否为，#0
start slave; //启动
//主库和从库 show processlist\G 查看同步状态
主库 有 Binlog Dump 线程
从库 有waiting for the slave I/O thread to update it和Waiting for master to send event 线程
slave-skip-errors = 1032，1062
提示：类似由于入库重复导致的失败可以忽略，其他情况是不是可以忽略需要根据不同公司的具体业务来评估
其他可能引起复制故障的原因：
·MySQL自身的原因及人为重复插入数据。
·不同的数据库版本会引起不同步，低版本到高版本可以，但是高版本不能往低版本同步。
·MySQL的运行错误或程序bug。
·binlog记录模式，例如：row level模式就比默认的语句模式要好。
MySQL主从复制延迟问题的原因及解决方案
问题一：主库的从库太多，导致复制延迟。
从库数量以3~5个为宜，要复制的从节点数量过多，会导致复制延迟。
问题二：从库硬件比主库差，导致复制延迟。
查看Master和Slave的系统配置，可能会因为机器配置不当，包括磁盘I/O、CPU、内存等
各方面因素造成复制的延迟。这一般发生在高并发大数据量写入场景中。
问题三：慢SQL语句过多。
假如一条SQL语句执行时间是20秒，那么从执行完毕到从库上能查到数据至少需要20秒，这样就延迟20秒了。
一般要把SQL语句的优化作为常规工作，不断地进行监控和优化，如果单个SQL的写入时间长，可以修改后分多次写入。通过查看慢查询日志或show full processlist命令，找出执行时间长的查询语句或大的事务。
问题四：主从复制的设计问题。
例如，主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟。更高版本的MySQL可以支持多线程复制，门户网站则会自己开发多线程同步功能。
问题五：主从库之间的网络延迟。
主从库的网卡、网线、连接的交换机等网络设备都可能成为复制的瓶颈，导致复制延迟，另外，跨公网主从复制很容易导致主从复制延迟。
问题六：主库读写压力大，导致复制延迟。主库硬件要搞好一点，架构的前端要加buffer及缓存层。
通过read-only参数让从库只读访问
read-only参数选项可以让从服务器只允许来自从服务器线程或具有SUPER权限的数据库用户进行更新，确保从服务器不接受来自用户端的非法用户更新。
read-only参数允许数据库更新的条件为：·具有SUPER权限的用户可以更新，不受read-only参数影响，例如：管理员root。
·来自从服务器线程可以更新，不受read-only参数影响，例如：前文的db用户。在生产环境中，可以在从库Slave中使用read-only参数，确保从库数据不被非法更新。
read-only参数的配置方法如下。
在my.cnf里[mysqld]模块下加read-only参数重启数据库，配置如下：
[mysqld]
read-only