一些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许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。