一些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:
另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
