1、 1）Statement-based replication 2）Row-based replication3）原理概述图 环境：主机名称IP地址系统数据库版本master192.168.116.129CentOS 5.4mysql-5.1.48.tar.gzslave192.168.116.131 Master 服务器，修改server-id、开启二进制日志、及为从机授权rootmaster opt# vim /etc/fmysqldlog-bin=mysql-binserver-id = 1mysql grant replication slave on *.* to repl192.16
2、8.16.131 identified by 123456;flush privileges;show grants for repl192.168.116.131 备注：对innodb来说，为了保证持久性及一致性，配置文件应添加innodb_flush_log_at_trx_commit=1sync_binlog=1 Slave服务器，修改server-id、开启二进制日志 至此，配置修改完成，下面为操作为保证master 和salve上的数据一致， 然后再开启slave上的同步进程 场景1：master 和slave上的数据库 1）初始化新安装 2）未新建任何应用库 3）未对外提供服务 操
3、作： master服务器： Slave 服务器： 执行命令： CHANGE MASTER TO MASTER_HOST=192.168.116.129,MASTER_PORT=3306,MASTER_USER=repl, MASTER_PASSWORD=,Master_Log_File=mysql-bin.000001,Master_Log_Pos=81639521;start slave;show slave status G 同步完成,类似如下状态：场景2： 1）master 已新建库，并已包含数据 2）master服务未对外提供服务保证主库与从库数据一致，然后再开启从库的同步操作 方法：
4、 1）利用mysqldumprootmaster opt# mysqldump -all-databases -lock-all-tables all_dbback.sql 或者添加master-data参数，自动带有change master 的定位信息：rootmaster opt#mysqldump -all-databases -master-data 将导出来的数据到slave库上恢复。 2）拷贝数据文件show variables like datadir -获取数据库数据库位置rootmaster opt#mysqladmin shutdown -关闭数据库，确保一致性将数据库目
5、录打包或者其他方法拷贝到slave服务器启动master 数据库，启动slave数据库、开启同步。场景3： 1）master应用库已对外提供服务，并不断有访问及数据更新 此操作在动态添加从库介绍（2）主主结构： 与主从结构不同之处： 利用auto_increment_increment、auto_increment_offset 控制auto_increment的值 计算方法：auto_increment=auto_increment_offset+N*auto_increment_increment 如，主库： auto_increment_offset=1 、auto_increment_
6、increment=2 1+1*2、1+2*2、1+3*2、1+4*2 auto_increment=1、3、5、7、9 从库： auto_increment_offset=2 、auto_increment_increment=2 2+1*2、2+2*2、2+3*2、2+4*2 auto_increment=2、4、6、8、10 来确保当2个数据库同时进行insert 插入时，不会产生auto_increment主键冲突； 由此来达到2个数据库可以同时进行数据插入的效果。 具体操作： 修改配置文件：master1：rootmaster opt#vim /etc/fauto_increment
7、_offset=1 auto_increment_increment=2master2rootmaster2 opt#vim /etc/fauto_increment_offset=2 备注： 1）由于解决不了2台服务器之间的全局事务一致性， 此模式只能算作主从模式的一种改进，可用于HA方案中的主从快速切换。 2）同时，即使解决了全局事务一致性，在写入和修改比较频繁的场景下， 由于auto_increment的不连续性，将会产生大量的数据碎片， 导致数据库变慢。 （3）一主多从： 1）一主多从 场景:可用于写入较少,主库压力不大且读取频繁的场景,主要用于读写分离 2）一主一从多从 原因：由于在
8、主库上进行的所有DML语句都会复制到从库 （即使指定了replicate-do-db），当从库较多时，将会对主库造成较大的 压力，即占用主库的CPU、IO、及带宽资源，为保证主库效率，可以在主 库后只对应一个从库，再由此从库对其他从库进行分发。 （4）高可用性: 场景：主要用于主从模式或者主主模式下，当因电源故障、网络故障、 服务器故障或mysql bug，造成的服务器down机、网络中断、或者mysql服 务异常退出而导致mysql无法正常对外提供服务时，另外一台MysQL服务能及 时发现，并即时接管并对外提供服务；尽量减少服务中断时间。5.5版本开始支持半同步复制，5.5之前及5.1版本都
9、为异步复制。 也就是说，5.1版本之前，master不会监控相应的sql是否 已 传到slave服务器。 5.5版本，支持半同步复制，至少确定sql已传送到一个slave上，然后 才将结果返送回客户端，但也只是确保已传送到，并不确保slave已执行。 Mysql同步的这种不完整性，导致了： 1）主库和从库的同步状态需要监控 2）在对数据完整性要求很严格的情况下,发生主从切换时， 都需要DBA对数据完整性进行审查和确认 3）对跨机房及跨地域的mysql复制，需要定期检查数据完整性 实现：lvs、keepalived或其他的硬件均衡负载设备。 keepalived具体实施步骤，可参见相关文档。 1
10、）MMM -Multi-Master Replicatioin Manager for MySQL 适用于管理大规模MySQL主从关系也是一个很好的HA实施方案， 同时对MySQL的针对性也很强 具体实施方案，可参见： 2）amoeba读写分离+MMM 具体实施，可参见： 所有的需求及操作都应按照实际的生产环境来进行，场景不同，采用的方法也不同。 场景1：当前master库负载较低，业务应用可以承受一定时间内数据无法写入。flush tables with read lock; -对主库加读锁,只允许读,不允许写show master status; -获取当前主库日志的名称及位置再将主库上的
11、数据导出unlock tables; -释放读锁，让数据库恢复正常状态将数据在从库上进行恢复设置主从开启同步 场景2：当前主库负载较高，且业务应用不允许数据库服务器任何的中断 此时，为了获取与主库数据的一致性，应用mysqldump 或者 Xtrabackupmysqldump -F -single-transaction -u xxx -pxxx dbname dbname.sqlshow master logs; -获取最新的日志文件名称将备份出的数据在从库上进行恢复指定从库从master最新二进制日志的开始位置开始读取 从机：Mysqlshow slave status; 比较重要的参数： Slave_IO_State、Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master 正常情况下，其对应的值： Slave_IO_State：Waiting for master to send event Slave_IO_Running：Yes Slave_SQL_Running： Seconds_Behind_Master： （3）特殊场景及处理 1.从MySQL本身设计原因，从库的Slave SQL进程只有一个。 当主库处于并发操作，且负载高时，从库的单sql进程的执行速度无
