一些mysql版本并不会开启二进制日志，所以一定要检查是否开启。如果一开始没开启，在以后需要开启，则必须重启数据库服务器，而数据库服务器重启会对业务造成很大影响。所以，尽管二进制日志会对性能有稍许影响，所以，无论是否要用复制、备份功能(增量日志也依赖二进制日志)，都建议开启

        目前mysql支持两种复制类型：

                1.二进制日志点

                2.GTID（mysql>=5.7推荐使用）

        有些配置要重启后才能生效，为了不影响数据库的正常使用，最好在上线之前就配置好，特别是master服务器的配置更应该做为初始参数配置好

        log_bin：mysql-bin为日志文件前缀（之所以把日志文件和数据文件分开放，是为了提高io性能）

        server_id：用来区分不同服务器

        log_bin：mysql-bin为日志文件前缀（之所以把日志文件和数据文件分开放，是为了提高io性能）

        server_id：用来区分不同服务器

        relay_log：slave的中继日志也应该和数据文件分开，以提高io性能

        read_only：只读（使所有没有super权限的用户在从服务器上不能执行写操作的，不论这个用户是否具备写权限。这样做的好处是避免误操作写到从服务器上造成主从不一致的问题。但这个参数不能限制具有super权限的用户，比如root帐号。为了解决这个问题，mysql5.7之后引入了super_read_only这个参数将具备super权限的用户也限制了不能在从服务器上做写操作）

        skip_slave_start：在slave服务器重启时不会自动启动复制链路（默认情况下mysql在slave重启时会自动启动复制链路，如果存在问题，则主从复制链路会中断。所以正常情况下，我们应该在服务器重启后检查是否存在问题，然后手动启动主从复制链路）

        master_info_repository和relay_log_info_repository：把主从服务器的信息存储到innodb表中，默认情况下是存储到文件系统中的，这样如果从服务器出现宕机，则很容易出现文件记录和实际同步信息不同步的情况。而把相关信息存储到表中，可以利用innodb丰富的恢复机制保证记录数据的一致性

在master上建立复制帐号：

（注意：只设置了该有的权限REPLICATION和SLAVE权限）

初始化slave数据：

启动基于日志点的复制链路：

主从复制演示：

主服务器配置：

        先看下主服务器的binlog日志是否开启，以及配置好server-id(这里配置为ip的后三位)：

从服务器(slave)配置：

        配置server-id和relay_log、master_info_repository、relay_log_info_repository，再加上read_only

        手动将master的server-id改为100（由于未重启master）：

        slave并没有业务访问，所以是可以重启的：

        （如果是mysql5.7及以上版本，还有个问题要注意：增加了个uuid值，默认情况下在data目录下有个auto.cnf文件中，如果用镜像方式安装的mysql服务器，server-uuid应该是一样的，所以需要将auto.cnf删掉，再重启自动生成一个新的uuid值。uuid相同主从复制会出现问题）

在主服务器上建立复制帐号，并授权:

        (本例中：从服务器全在192.168.3.%网段上)

mysql全备来初始化从服务器的数据：

        将全备拷贝到从服务器上：

复制链路的配置（从服务器）：

        （dba_repl是master创建的主从复制帐号，master_log_file是主服务器的二进制日志文件，master_log_pos是日志点）

                查看master服务器的master_log_file和master_log_pos的方式（举例，显示的和本例无关）：

        启动从服务器：

        检查slave的状态，是否启动：

                执行命令show slave status: