一、单个数据库服务器的缺点 数据库服务器存在单点问题; 数据库服务器资源无法满足增长的读写请求; 高峰时数据库连接数经常超过上限。 二、如何解决单点问题 增加额外的数据库服务器,组建数据库
1、主库将变更写入到主库的binlog中
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服务器都是使用的MySQL5.7,所以我们可以使用全备的方式进行:
mysqldump --master-data=2 -uroot -p -A --single-transaction -R --triggers
4、启动基于日志点的复制链路
在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复制的限制:
4和5中选一个执行即可。
1. 先对主服务器进行配置
由于主服务器一直在运行着,在生产环境中主服务器是很少会重启的,如果主服务器重启,会造成正常的业务访问的中断,所以在服务器启动之前就启动了二进制日志。
这里不需要重启主服务器了,由于主服务器的默认server_id=1,我们虽然在配置文件中更改了它的值 ,但实际运行环境中并没有改变。
我们可以查看一下当前server_id:
mysql> show variables like "%server_id%";
可以通过以下命令动态的进行修改:
mysql> set global server_id = 100;
2. 再对从服务器进行配置
修改完从服务器配置后,重启MySQL服务器。如果使用的是MySQL5.7版本的需要注意:
以上我们就完成了主从复制的配置,接下来我们要在主服务器上建立复制账号。
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.000017
Slave_IO_Running:Yes
Slave_SQL_Running: Yes
说明启动成功了,可以在主服务器上插入数据,在从服务上查看数据是否同步过来了。
虽然主从复制增加了一个数据库副本,但从数据库和主数据库的数据最终会是一致的。之所以说是最终一致,因为MySQL复制是异步的,正常情况下主从复制数据之间会有一个微小的延迟。
通过这个数据库副本看似解决了数据库单点问题,但并不完美:因为这种架构下,如果主服务器宕机,需要手动切换从服务器,业务中断不能忍受,不能满足应用高可用的要求。
--结束END--
本文标题: MySQL主从复制虽好,能完美解决数据库单点问题吗?
本文链接: https://lsjlt.com/news/7427.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0