mysql主从配置

MySQL的Replication（英文为复制）是一个多MySQL数据库做主从同步的方案，特点是异步复制，广泛用在各种对MySQL有更高性能、更高可靠性要求的场合。与之对应的是另一个同步技术是MySQL Cluster，但因为MySQL Cluster配置比较复杂，所以使用者较少。 MySQL的 Replication是一个异步复制的过程（mysql5.1.7以上版本分为异步复制和半同步两种模式），它是从一个Mysql instance（instance英文为实例）(我们称之为Master)复制到另一个Mysql instance(我们称之slave)。在master与slave之间实现整个复制过程主要由三个线程来完成，其中两个线程(SQL线程和IO线程) 在slave端，另外一个线程(IO线程)在master端。 要实现MySQL的 Replication，首先必须打开master端的binlog (mysql-bin.xxxxxx)日志功能，否则无法实现mysql的主从复制。因为mysql的整个主从复制过程实际上就是：slave端从 master端获取binlog日志，然后再在自己身上完全顺序的执行该日志中所记录的各种SQL操作。 有关具体如何开启mysql的binlog日志功能，请大家自己在网上搜。 MySQL主从复制的基本交互过程，如下： 1

MySQL主从复制之半同步模式 MySQL半同步介绍： 一般情况下MySQL默认复制模式为异步，何为异步？简单的说就是主服务器上的I/O threads 将binlog写入二进制日志中就返回给客户端一个结果，无需等待二进制日志是否成功发送到从库和从库上是否成功完成relay log的写入和SQL threads从relay log中提前二进制日志写入自己binlog的过程，异步模式的缺点就是一旦主库写入binlog日志后发生宕机，此时从库还未完成对主库传送过来binlog的读写存储操作，那么从库就会发生数据丢失的现象。所以这里就出现了另外一种复制模式，即半同步模式。 在半同步模式下，主库将binlog日志信息写入到日志中，然后等待从库完成后面的接收读取和存储操作，然后返回主库一个明确信息，即从库接收完主库传递过来的binlog内容已经写入到自己的relay log中，才会通知主库上的等待线程，该操作已经完成，才是主库接收到从库发过来的信息就会进入下一个同步操作动作，如果在此时等待超时，超过主库中设置的超时时间限制（一般是rpl_semi_sync_master_timeout的值），则关闭半同步，并切换为异步模式，直到至少有一台从库告诉主库已经接收到主库传送过来的binlog信息为止。 MySQL半同步特点： 1、从库会在连接到主库时告诉主库，它是不是匹配了半同步 2

1、半同步复制简介 　　何为半同步复制模式呢？在此我们先了解异步复制模式，这是MySQL的默认复制选项。异步复制即是master数据库把binlog日志发送给slave数据库，然后就没有了然后了。在此暴露一个问题，当slave服务器发生故障了，那么肯定会导致主从数据库服务器的数据不一致。 　　为了解决上面的问题，MySQL5.5引入一种叫做半同步复制模式。开启这种模式，可以保证slave数据库接收完master数据库发送过来的binlog日志并写入自己的中继日志中，然后反馈给master数据库，告知已经复制完毕。 　　开启这种模式后，当出现超时，主数据库将会自动转为异步复制模式，直到至少有一台从服务器接受到主数据库的binlog，并且反馈给主数据库。这时主数据库才会切换回半同步复制模式。 注意： 半同步复制模式必须在主服务器和从服务器同时中开启，否则将会默认为异步复制模式。 2、环境说明 　　两台linux虚拟主机 　　Linux版本CentOS6.6、MySQL 5.5 　　ip：192.168.95.11（主）、192.168.95.12（从） 3、安装与配置 　　3.1、安装前提 　　　　1、必须是MySQL5.5或者以上 　　　　2、MySQL必须有自动加载功能，即have_dynamic_loading变量为YES（因为我们是在MySQL里面来加载安装这个功能插件） 　　

1、概述 主从复制存在三种类型：异步复制、同步复制以及半同步复制，下面根据手册上解释逐一说明一下。 异步复制： 主库将更新的事件写入binlog，准备好的从库获取这些binlong进行回放。这无法保证所有从库都接到这些事件。 With asynchronous replication, the master writes events to its binary log and slaves request them when they are ready. There is no guarantee that any event will ever reach any slave. 同步复制： 主库提交一个事务，在返回结果给客户端前，需要等待所有从库都提交了这个事务。缺点就是主库在完成一个事务前存在很多延迟 在MySQL Cluster NDB中是同步的 http://dev.mysql.com/doc/refman/5.5/en/replication.html With fully synchronous replication, when a master commits a transaction, all slaves also will have committed the transaction before the master returns to the

一、简介 从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous replication） 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 下面来看看半同步复制的原理图： 半同步复制的潜在问题 客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种：

MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维 护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那 时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。 为什么使用主从复制？ 1、主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。 2、通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。但是不要同时在主从服务器上进行更新，这样可能引起冲突。 3、使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。 MySQL使用3个线程来执行复制功能(其中1个在主服务器上，另两个在从服务器上。当发出START SLAVE时，从服务器创建一个I/O线程，以连接主服务器并让主服务器发送二进制日志。主服务器创建一个线程将二进制日志中的内容发送到从服务器。从服 务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。第3个线程是SQL线程，从服务器使用此线程读取中继日志并执行日 志中包含的更新。SHOW

本文介绍了mysql主从，实现mysql的双向同步复制。 MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。 为什么使用主从复制？ 1、主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。 2、通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。但是不要同时在主从服务器上进行更新，这样可能引起冲突。 3、使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。 MySQL使用3个线程来执行复制功能(其中1个在主服务器上，另两个在从服务器上。当发出START SLAVE时，从服务器创建一个I/O线程，以连接主服务器并让主服务器发送二进制日志。主服务器创建一个线程将二进制日志中的内容发送到从服务器。从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。第3个线程是SQL线程

第1章 MySQL主从复制 1.1 数据库损坏了？ 主要理解为：业务不能使用数据库 外在原因： 1、网络问题 2、业务应用有问题，客户端损坏 数据库本身的原因： 1、物理损坏：机器坏了、硬盘坏了、存储坏了 2、逻辑损坏：误drop、delete、truncate、、update。 解决方案： 1、备份 2、主从复制 1.2 MySQL主从复制 1.2.1 MySQL复制概念 指将主数据库的DDL和DML操作通过二进制日志传到复制服务器上，然后在复制服务器上将这些日志文件重新执行，从而使复制服务器和主服务器的数据保持同步。复制过程中一个服务器充当主服务器（master），而一个或多个其它服务器充当从服务器（slaves）。主服务器将更新重新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器、从服务器在日志中读取的最后一次成功更新的位置。从服务器接受从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 复制的用途： 通过主从复制（master-slave）的方式来同步数据，再通过读写分离（mysql-proxy）来提升数据库的并发负载能力，或者用来作为主备机的设计，保证在主机停止响应之后在很短的时间内就可以将应用切换到备机上继续运行。 优势： （1）数据库集群系统具有多个数据库节点

前言 数据库实时备份的需求很常见，MySQL本身提供了 Replication 机制，摘译官方介绍如下： MySQL Replication 可以将一个主数据库中的数据同步到一个或多个从数据库中。并且这个同步过程默认以异步方式工作，不需要保持主从数据库的实时连接（即允许连接中断）。同时允许自定义配置需同步的数据库及数据表。 MySQL Replication 的优点及应用场景如下： 1、通过 MySQL Replication 实现负载均衡与读写分离（主数据库仅更新，从数据库仅读取），提升数据库性能。 2、通过 MySQL Replication 实现数据的实时备份，保证数据安全。 3、通过 MySQL Replication 实现数据的离线分析（主数据库生成数据，从数据库分析计算不影响主数据库性能）。 4、数据分发。 MySQL Replication完整的官方文档请参阅： https://dev.mysql.com/doc/refman/5.7/en/replication.html 剑 http://www.cnblogs.com/wu-jian 工作原理 1、Master中的所有数据库变更事件写入Binary Log文件 2、当在Slave中执行“SLAVE START”命令时，开启Slave I/O Thread，并连接Master 3、Master侦测到Slave I

Mysql 主从 同步 读写 分离 目录 一． 概述 4 二. 实验目的 4 三． 试验环境 4 四. 方案 说明 4 五．Mysql 主从同步配置 5 1. 安装与初始化数据库 5 2. 主从服务器均授予 MySQL 远程登录权限。 5 3. 主从同步配置 5 六．Amoeba 读写分离配置 13 1. Amoeba 下载安装 13 2. 安装 Java 13 3. 修改 amoeba 的配置文件 amoeba.xml 和 dbServers.xml 的配置。 14 4. 启动 amoeba 进行测试。 20 七．读写分离测试。 21 1. 写测试 21 2. 读测试 24 一． 概述 Amoeba是一个以MySQL为底层数据存储，并对应用提供MySQL协议接口的proxy。它集中地响应应用的请求，依据用户事先设置的规则，将SQL请求发送到特定的数据库上执行。基于此可以实现负载均衡、 读写分离 、高可用性等需求。与MySQL官方的MySQL Proxy相比，作者强调的是amoeba配置的方便（基于XML的配置文件，用SQLJEP语法书写规则，比基于lua脚本的MySQL Proxy简单）。 二. 实验目的 实际的生产环境中，由单台 Mysql 作为独立的数据库是完全不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。通过主从同步（ Master-Slave