MySQL支持以下几种常见的复制类型:
1. 提高读性能:通过设置从服务器(Slave),读操作可以被分摊到主服务器(Master)和从服务器上,从而提高整体的读取性能。主服务器负责处理写操作,从服务器负责处理读操作,从而降低主服务器的负载,提升整个系统的吞吐量。
例如:在业务复杂的系统中,有这么一个情景,有一句sql语句需要锁表,导致暂时不能使用读的服务,那么就很影响运行中的业务,使用主从复制,让主库负责写,从库负责读,这样,即使主库出现了锁表的情景,通过读从库也可以保证业务的正常运作。
2. 数据冗余和备份:通过主从复制,从服务器上的数据是主服务器的冗余副本。在主服务器发生故障时,从服务器仍然可以提供服务,并且可以通过将某个从服务器提升为新的主服务器来快速恢复服务。此外,从服务器也可以用于定期的备份操作,以确保数据的安全性和可恢复性。
3. 高可用性:通过主从复制,可以实现数据库的故障转移和高可用性。当主服务器发生故障时,可以手动或自动将某个从服务器提升为新的主服务器,继续提供数据库服务,从而实现快速的故障恢复。
4. 数据分析和报表生成:由于从服务器可以处理读操作,可以将其用于数据库的数据分析和报表生成等工作。这样可以避免对主服务器造成额外的负载,同时提供实时的数据分析和报表服务。
5. 数据分发和跨地域部署:主从复制可以用于将数据分发到不同的地理位置的从服务器上,从而实现跨地域的数据访问和部署。这对于全球化的应用程序和多地域灾备是非常有用的。
3、架构的扩展。业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问的频率,提高单个机器的I/O性能。
主从复制是一种常用的数据备份和恢复方法。它的基本架构包括主服务器(master)和从服务器(slave)两部分。主服务器负责写操作,而从服务器负责读操作。Mysql的主从复制中主要有三个线程:master(binlog dump thread)、slave(I/O thread 、SQL thread)
主从复制的原理是通过基于日志的复制方式实现数据的同步。当主服务器上发生数据变更时,会将这些变更写入二进制日志(Binary Log)中。从服务器通过连接到主服务器,请求从主服务器获取二进制日志,并将这些日志应用到自己的数据库中。
主从复制的基本原理:
1. 主服务器生成二进制日志:在主服务器上,所有的写操作(例如插入、更新、删除)都会被记录在二进制日志中。这些写操作以事件(event)的形式被记录下来,二进制日志包含了数据库变更的详细信息。
2. 从服务器连接到主服务器:从服务器通过连接到主服务器,建立一个复制连接。在连接建立时,从服务器会获取到主服务器上当前的二进制日志文件名和位置,作为复制的起点。
3. 从服务器请求复制数据:从服务器会向主服务器发送一个复制请求,请求从当前的二进制日志位置之后的写操作事件。主服务器根据复制请求,将二进制日志中的事件发送给从服务器。
4. 从服务器应用复制日志:从服务器接收到主服务器发送的二进制日志后,会解析并应用这些事件到自己的数据库中。从服务器会按照事件的顺序依次执行,以保持数据的一致性。
5. 复制链路的维护和监控:主从复制过程中,主服务器会持续记录二进制日志,而从服务器会持续请求和应用这些日志。复制链路需要进行监控和维护,以确保复制的正常运行和数据的可靠性。
注:主从复制是异步的,从服务器在应用写操作之前,并不等待主服务器的确认。因此,从服务器上的数据可能会有一定的延迟。
主从复制的基本架构流程:
1. 配置主服务器:在主服务器上,需要开启二进制日志(Binary Log)功能,该功能记录了主服务器上的所有写操作,包括更新、删除和插入。同时,需要配置主服务器的唯一标识(server_id)。
2. 配置从服务器:在从服务器上,需要配置正确的主服务器地址和连接参数,包括主服务器的IP地址、端口号、用户名和密码等。同时,也需要配置从服务器的唯一标识(server_id)。
3. 启动复制:在从服务器上启动复制进程,连接到主服务器并请求复制数据。主服务器将发送二进制日志文件中的写操作事件(event)给从服务器,从服务器接收并应用这些事件,将数据复制到自己的数据库。
4. 复制过程:复制过程主要包括两个步骤:从服务器请求主服务器的二进制日志,主服务器将日志发送给从服务器;从服务器解析并应用日志中的事件到自己的数据库,保持与主服务器的数据一致性。
5. 复制链路的监控和维护:可以通过监控工具或命令来查看主从服务器的复制状态和延迟情况。同时,也需要定期备份和维护从服务器,确保数据的安全性和可恢复性。
两台机器,一主一从。
主(master):192.168.136.134 port:3306
从(slave):192.168.136.135 port:3306
[mysqld]
log_bin = mysql-bin
server_id = 120
设置完成并保存后记得重启服务
systemctl restart mysqld
grant replication slave on *.* to 'slave_test'@'192.168.136.%' identified by '123456';
注:这里的密码为简易密码,需要更改密码策略否则会报错,可以使用上一步骤中的validate_password=off关闭密码策略(同样地方修改)。
mysql> show grants for 'slave_test'@'192.168.136.%';
为后面备份准备,注意生产环境要提前申请停机时间;
mysql> flush tables with read lock;
#提示:如果超过设置时间不操作会自动解锁。
mysql> show variables like '%timeout%';
FLUSH TABLES WITH READ LOCK; 是一个MySQL语句,它的作用是在当前会话中锁定所有表,并使它们处于只读状态。这个命令常用于备份数据库或进行一些需要确保数据一致性的操作。
当执行这个命令时,MySQL将锁定所有的表,防止其他会话对这些表进行写入操作,从而保证了数据的一致性。只有在当前会话释放这些表的锁之后,其他会话才能对这些表进行写入操作。
需要注意的是,执行FLUSH TABLES WITH READ LOCK;之后,如果需要对表进行任何修改操作,都需要先执行UNLOCK TABLES;来释放表的锁定状态。这样其他会话才能对表进行写入操作。
SHOW VARIABLES LIKE ‘%timeout%’; 是一个MySQL查询语句,用于查看与超时相关的变量配置。执行该语句后,MySQL将返回所有包含"timeout"关键字的系统变量和它们的值。
查看主库状态,即当前日志文件名和二进制日志偏移量
show master status;
mysqldump -uroot -p -A -B | gzip > /backup/mysql_bak.$(date +%F).sql.gz
释放表的锁定状态。这样其他会话才能对表进行写入操作。
mysql> unlock tables;
scp /backup/mysql_bak.2023-07-17.sql.gz 192.168.136.135:/backups/
[mysqld]
server-id=130
我这里是新开的虚拟机还没设置bin_log参数所以没有关闭,有的话只需要注释掉即可。
cd /server/backup/
gzip -d mysql_bak.2015-11-18.sql.gz
mysql -uroot -p < mysql_bak.2015-11-18.sql
#检查还原:
mysql -uroot -p -e 'show databases;'
主库的数据库如下:
从库的数据库:
mysql> change master to
MASTER_HOST='192.168.136.134',
MASTER_PORT=3306,
MASTER_USER='slave_test',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=455;
mysql> start slave;
# 检查状态:
mysql> show slave status\G