本文主要给大家介绍MySQL主从复制解决数据库单点问题讲义，其所涉及的东西，从理论知识来获悉，有很多书籍、文献可供大家参考，从现实意义角度出发，创新互联累计多年的实践经验可分享给大家。
专业从事网站制作、成都网站建设,高端网站制作设计,成都微信小程序,网站推广的成都做网站的公司。优秀技术团队竭力真诚服务，采用H5高端网站建设+CSS3前端渲染技术，成都响应式网站建设，让网站在手机、平板、PC、微信下都能呈现。建站过程建立专项小组，与您实时在线互动，随时提供解决方案，畅聊想法和感受。
数据库服务器存在单点问题；
数据库服务器资源无法满足增长的读写请求；
增加额外的数据库服务器，组建数据库集群；
同一集群中的数据库服务器需要具有相同的数据；
1、主库将变更写入到主库的binlog中
一些MySQL版本并不会开启二进制日志，所以一定要检查是否开启；
如果刚开始没有开启，后面再进行开启的话，需要重启数据库才能生效，而且数据库的重启往往会对业务造成很大的影响；
2、从库的IO线程在指定位置读取主库binlog内容存储到本地的中继日志（Relay Log）中
要完成二进制日志的传输过程，MySQL会在从服务器上启动一个工作线程，称为IO线程，这个IO线程会跟主数据库建立一个普通的客户端连接，然后在主服务器上启动一个特殊的二进制转储线程称为binlogdown线程。
从库上的IO线程通过这个二进制转储线程来读取主库上的二进制事件，如果该事件追赶上主库，则会进入sleep状态，直到主库发起信号通知有新事件产生时，才会被唤醒，relay log的格式和binlog格式是完全相同的，
可以使用mysqlbinlog来读取relay log中的内容。
3、从库的SQL线程读取Relay Log日志中的内容，并在从库中重放
SQL线程所执行的事件，我们可以通过配置选项来决定是否要写入到从服务器的二进制日志中。
目前MySQL支持两种复制类型：
基于二进制日志点的复制
1、配置主从数据库服务器参数
有些参数配置后需要数据库重启才能生效，为了不影响数据库的正常使用，我们最好在服务器上线的同时就把参数都配置好。特别是master服务器的参数，更应该作为服务器初始参数来进行配置。
master服务器：
slave 服务器：
2、在master服务器上创建用于复制的数据库账号
用于IO线程连接master服务器获取binlog日志，需要* REPLICATION SLAVE** 权限：
重庆分公司
重庆分公司
create user 'repl'@'ip段' identified by 'password';
grant replication slave on *.* to 'repl'@'ip段';3、备份master服务器上的数据并初始化slave服务器数据
建议主从数据库服务器采用相同的MySQL版本；
建议使用全库备份的方式初始化slave数据。
采用相同版本的好处：
我们可以使用全备的方式来初始化slave数据，还可以避免不同版本之间的差异造成数据库同步失败的问题。
如果我们使用的主从复制的服务器MySQL版本不同，则一定要注意master上的版本一定要低于slave服务器，不然同步的时候就可能出现错误。
由于我们演示过程中的MySQL服务器都是使用的MySQL5.7，所以我们可以使用全备的方式进行：
mysqldump --master-data=2 -uroot -p -A --single-transaction -R --triggers4、启动基于日志点的复制链路
在slave服务器上运行，MySQL命令：
CHANGE MASTER TO
MASTER_HOST= 'master_host_ip',
MASTER_USER= 'repl',
MASTER_PASSWORD = 'password',
MASTER_LOG_FILE='mysql_log_file_name',
MASTER_LOG_POS=xxxxxx;5、启动基于GTID的复制链路
GTID：全局事务ID，GTID可以保证每一个在主上提交的事务，在复制集群中可以生成一个唯一的ID值，要使用基于GTID的复制，我们要在主从复制的配置文件中同时加入以下配置项。
MySQL配置：
gtid_mode=on
# 是否启动gtid模式，启动了此模式会在二进制日志中会额外记录每个事务的GTID标识符
enforce-gtid-consistency
# 强制gtid一致性，用于保证启动gtid后事务的安全
log-slave-updates = on
# mysql5.6一定要启用参数，5.7可以不启用MySQL命令：
CHANGE MASTER TO
MASTER_HOST= 'master_host_ip',
MASTER_USER= 'repl',
MASTER_PASSWORD = 'password',
MASTER_AUTO_POSITION=1;GTID复制的限制：
无法再使用create table ... select语句建立表，只能先create表，再insert数据；
无法在事务中使用create temporary table建立临时表；
4和5中选一个执行即可。
1. 先对主服务器进行配置
由于主服务器一直在运行着，在生产环境中主服务器是很少会重启的，如果主服务器重启，会造成正常的业务访问的中断，所以在服务器启动之前就启动了二进制日志。
这里不需要重启主服务器了，由于主服务器的默认server_id=1，我们虽然在配置文件中更改了它的值 ，但实际运行环境中并没有改变。
我们可以查看一下当前server_id：
mysql> show variables like '%server_id%';可以通过以下命令动态的进行修改：
mysql> set global server_id = 100;2. 再对从服务器进行配置
修改完从服务器配置后，重启MySQL服务器。如果使用的是MySQL5.7版本的需要注意：
MySQL5.7增加了server-uuid值，默认情况下载auto.cnf文件中，如果是使用的镜像的方式安装，可能大家的uuid一样 ，所以需要把auto.cnf文件删除掉。MySQL重启后会自动重新生成uuid的值，这样就可以保证不同服务器上的MySQL实例的uuid的值是不一样的；
以上我们就完成了主从复制的配置，接下来我们要在主服务器上建立复制账号。
3. 在MySQL主服务器上建立MySQL复制账号
mysql> create user 'dba_repl'@'192.168.3.%' identified by '123456';
mysql> grant replication slave on *.* to 'dba_repl'@'192.168.3.%';4. 建立好复制账号以后，通过mysql主服务器上的全备初始化从服务器上数据
进行全备：
[root@localhost data]# cd /data/db_backup/
[root@localhost db_backup]# mysqldump -uroot -p --master-data=1 --single-transaction --routines --triggers --events --all-databases > all.sql
Enter password:将其拷贝到从服务器上：
[root@localhost db_backup]# scp all.sql root@192.168.3.101:/root在从服务器上恢复备份进行初始化：
[root@Node2 ~]# mysql -uroot -p < all.sql初始化完成后，准备。
5. 从服务器进行基于日志点的复制链路的配置
mysql> change master to
master_host='192.168.3.100',
master_user='dba_repl',
master_password='123456',
MASTER_LOG_FILE='mysql-bin.000017',
MASTER_LOG_POS=663;
MASTER_LOG_FILE和MASTER_LOG_POS的值从全备文件中的CHANGE MASTER中获取以上复制链路的配置完成。
启动slave：
mysql> start slave;检查是否启动成功状态：
mysql> show slave status \G显示：
Relay_Master_Log_File: mysql-bin.000017Slave_IO_Running：YesSlave_SQL_Running: Yes说明启动成功了，可以在主服务器上插入数据，在从服务上查看数据是否同步过来了。
虽然主从复制增加了一个数据库副本，但从数据库和主数据库的数据最终会是一致的。之所以说是最终一致，因为MySQL复制是异步的，正常情况下主从复制数据之间会有一个微小的延迟。
通过这个数据库副本看似解决了数据库单点问题，但并不完美：因为这种架构下，如果主服务器宕机，需要手动切换从服务器，业务中断不能忍受，不能满足应用高可用的要求。
看了以上MySQL主从复制解决数据库单点问题讲义介绍，希望能给大家在实际运用中带来一定的帮助。本文由于篇幅有限，难免会有不足和需要补充的地方，大家可以继续关注创新互联行业资讯板块，会定期给大家更新行业新闻和知识，如有需要更加专业的解答，可在官网联系我们的24小时售前售后，随时帮您解答问题的。
