文章目录
主从复制
流程
- 首先在master上开启二进制日志
- master上数据发生变化,进行DML操作的时候,会产生二进制日志
- master上的dump线程会通知slave上的IO线程来拿二进制日志,IO线程拿到二进制日志后会写入到slave上的中继日志,然后SQL线程会去读取新产生的中继日志,重演二进制日志里的操作,从而达到slave和master上的数据一模一样,实现数据的一致性。
问题
- 是主服务器主动通知从服务器取二进制日志,还是从服务器每过一段时间就来取二进制文件。
主服务器通常会主动推送二进制日志事件给从服务器,而不是从服务器主动来取。
-
主服务器如何知道从服务器上已经有哪些数据了,需要从哪里开始给数据给服务器
MySQL主从复制中,主服务器确实需要知道从服务器已经存在哪些数据,才能知道从什么位置开始同步数据。
主服务器通过以下方式获知从服务器的数据状态:
-
在从服务器连接主服务器时,从服务器会发送它已有的binary log文件和位置给主服务器。主服务器据此判断从服务器的数据状态。
-
主服务器还会在从服务器连接时,检查从服务器的数据库和表等的状态,和主服务器进行比较,进一步判断从服务器的数据状态。
-
主从服务器初次建立连接时,如果从服务器数据为空,主服务器会自动从自己的binary log头开始复制所有数据到从服务器。
-
在正常复制过程中,主服务器也会持续记录每个从服务器的复制位置,以便断开重连后快速定位从哪里恢复复制。
所以MySQL通过上述机制,让主服务器能充分掌握从服务器的具体数据状态,从而实现从指定位置开始的增量复制。这使得MySQL的主从复制更加高效可靠。
-
-
是否任何一台机器都可以充当从服务器。不需要验证就开业去拿主服务的二进制日志
是的,基本上只要主服务器开启了二进制日志,已经配置了从服务器能够访问的用户和密码,以及具备了正确的主服务器的IP地址和端口,理论上任何一台装有MySQL的机器都可以配置成从服务器,并复制主服务器的二进制日志。
但是,请注意以下关键点:
-
安全性:任何具有正确用户名和密码的机器都可以尝试连接到主服务器并请求二进制日志,从而可能泄露敏感数据。因此,为了增强安全性,您应该使用身份验证,配置防火墙或使用VPN等方式使仅有特定IP的机器可以与主服务器通信,或者使用SSL连接以加密数据流。
-
服务器版本兼容性:虽然大多数时候,主从服务器的MySQL版本不需要完全一致,尤其是当主服务器版本低于从服务器版本时,但是如果主服务器版本高于从服务器版本,可能会导致一些新特性和命令不被从服务器识别,从而导致复制失败。因此,推荐配置相同版本的MySQL服为主从服务器。
-
数据一致性:从服务器需要与主服务器保持数据一致,这通常意味着从服务器需要与完成备份时主服务器的状态一致。如果数据不一致,复制过程可能会遇到错误。
总而言之,虽然任何一台装有MySQL的机器都可以配置为从服务器,但仍然需要考虑到安全性、版本兼容性和数据一致性等因素。
-
-
从服务器如何知道谁是它的主服务器呢?
-
maste-info文件的作用
-
relay-log.info文件的作用
-
master.info 和 relay-log.info在哪里?
为什么需要主从复制?
实验
-
安装好2台数据库服务的系统,然后安装好MySQL软件
-
在master上开启二进制日志
-
统一两天服务器的基础数据(保持数据一致)
-
基础数据
主
导出全部文件
[root@master-mysql backup]# mysqldump -uroot -p'123456' --all-databases >all_db.sql
清除二进制日志,因为有全备
root@(none) 16:12 mysql>reset master;
root@(none) 16:12 mysql>show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 154 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
master建立授权用户,给slave来复制二进制日志
这条命令在8版本不可以用了
grant replication slave on *.* to 'slave'@'192.168.2.%' identified by '12345';
grant replication slave on *.* to 'slave'@'192.168.2.%' identified by '123456';
flush privileges;
从
导入文件
[root@slave-msql backup]# mysql -uroot -p123456 <all_db.sql
给server_id
否则会失败
[mysqld]
socket=/data/mysql/mysql.sock
port = 3306
open_files_limit = 8192
innodb_buffer_pool_size = 512M
character-set-server=utf8
log_bin
server_id=2
配置master info
的信息
CHANGE MASTER TO MASTER_HOST='192.168.2.3',
MASTER_USER='slave',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
MASTER_LOG_FILE='master-mysql-bin.000001',
MASTER_LOG_POS=154;
查看slave是否配置成功
root@(none) 17:07 mysql>start slave;
root@(none) 17:08 mysql>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 192.168.2.3
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 154
Relay_Log_File: slave-msql-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
开启slave
root@(none) 17:49 mysql>start slave;
这样就是链接成功了
root@(none) 17:50 mysql>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.2.3
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-mysql-bin.000001
Read_Master_Log_Pos: 154
Relay_Log_File: slave-msql-relay-bin.000003
Relay_Log_Pos: 327
Relay_Master_Log_File: master-mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
主从问题
需要注意的是
如果两台机器直接进行克隆的
Slave_IO_Running: Connecting
要检查master
设置的账号和密码是否正确了。
首先在从数据库链接登录主数据库,查看是否能够成功登录
mysql -uslave -p'123456' -h192.168.2.4(主数据库分配的user和pwd以及主数据库的IP地址)
假如不能登录则需要关闭防火墙、selinux后重试
systemctl stop firewalld 关闭网络防火墙
systemctl disable firewalld 关闭开机自启动(永久关闭)
setenforce 1 #临时
#打开 /etc/selinux/config 文件,并将 SELINUX 的值设置为 "disabled":
SELINUX=disabled
还有可能是因为两台机器是直接复制的,两台机器的ppid都是一样的需要修改,在auto.cnf
文件进行修改
[root@slave-msql mysql]# cat auto.cnf
[auto]
server-uuid=9d91ff23-1bf2-11ee-8b36-000c29ad31a8
在业务不停的时候怎么增加一台从服务器
有业务跑的时候,position(位置不停变化),也需要进行基础数据的备份。
xtrabackup
Xtrabackup是一个由Percona开发的MySQL备份工具,它支持热备份和恢复,并且在备份过程中不会对MySQL服务器造成负载。Xtrabackup可以用于物理备份和恢复MySQL数据库,它能够备份InnoDB和XtraDB存储引擎的数据文件。
下面是Xtrabackup的一些主要特点和功能:
-
热备份:Xtrabackup能够在MySQL服务器运行时进行备份,而不会中断数据库的正常操作。这意味着您可以在生产环境中进行备份,而无需停止或减少对数据库的访问。
-
增量备份:Xtrabackup支持增量备份,它可以只备份自上次完整备份或增量备份以来发生更改的数据。这可以大大减少备份所需的时间和磁盘空间。
-
快速恢复:Xtrabackup能够快速恢复备份数据。它利用了InnoDB存储引擎的特性,如可重放日志(redo log),以加速恢复过程。
-
支持复制环境:Xtrabackup能够备份和恢复MySQL的主从复制环境,并保持复制关系的完整性。
-
压缩备份:Xtrabackup可以在备份过程中对数据进行压缩,从而减少备份文件的磁盘占用空间。
-
完整性检查:Xtrabackup提供了完整性检查工具,可以用于验证备份数据的完整性。
-
并行备份和恢复:Xtrabackup支持并行备份和恢复,可以充分利用多核处理器和多个磁盘。
总体而言,Xtrabackup是一个功能强大且灵活的MySQL备份工具,它提供了高性能的备份和恢复解决方案,并且适用于各种规模和复杂度的MySQL环境。
模式
MySQL的主从切换涉及不同的复制模式,包括异步复制、半同步复制和同步复制。这些复制模式决定了主数据库和从数据库之间数据复制的方式和可靠性级别。
-
异步复制(Asynchronous Replication):在异步复制模式下,主数据库将数据更改记录写入二进制日志,并异步地将日志传输给从数据库进行复制。主数据库将数据更改写入二进制日志后,不会等待从数据库的确认,而是立即返回给应用程序。这意味着主数据库可以继续处理其他操作而无需等待从数据库的响应。异步复制模式的优点是性能高,但可能会存在数据丢失的风险,因为主数据库无法确保从数据库已完全接收和应用了所有的数据更改。
-
半同步复制(Semi-Synchronous Replication):在半同步复制模式下,主数据库在提交事务之前,需要等待至少一个从数据库确认接收并应用了数据更改。主数据库将数据更改写入二进制日志后,会等待至少一个从数据库的确认,并确保数据复制的一致性。这提供了比异步复制更高的数据可靠性,减少了数据丢失的风险。但半同步复制的性能相对于异步复制来说稍低,因为主数据库需要等待从数据库的确认。
-
同步复制(Synchronous Replication):在同步复制模式下,主数据库在提交事务之前,需要等待所有从数据库确认接收并应用了数据更改。主数据库将数据更改写入二进制日志后,会等待所有从数据库的确认,确保数据复制的严格一致性。同步复制提供了最高的数据可靠性,几乎没有数据丢失的风险。然而,同步复制模式对性能的影响最大,因为主数据库需要等待所有从数据库的确认,这可能会引起一定的延迟。
半同步
MySQL的半同步复制(Semi-Synchronous Replication)是一种复制模式,提供了比异步复制更高的数据可靠性,同时在性能方面与同步复制进行了一定的折中。
在半同步复制模式下,当主数据库(Master)提交一个事务后,它会等待至少一个从数据库(Slave)**确认接收(这是和异步的主要区别)**并应用了数据更改,然后才向应用程序返回提交成功的响应。这确保了至少有一个从数据库与主数据库保持一致,减少了数据丢失的风险。
下面是半同步复制的工作原理和一些关键特点:
-
数据提交确认:主数据库在将数据更改写入二进制日志后,等待至少一个从数据库确认接收了数据更改。确认是通过从数据库发送一个ACK(确认)消息来完成的。
-
确认等待时间:主数据库等待从数据库发送确认消息的时间有一个设定的等待时间阈值。如果在等待时间内没有收到确认消息,主数据库将继续进行提交操作,而不会等待确认。
-
容错能力:半同步复制提供了一定的容错能力。如果一个从数据库发生故障或延迟导致确认消息未能及时到达主数据库,主数据库会将该从数据库切换为异步复制模式,并继续等待其他从数据库的确认。这样可以确保数据复制的持续进行,但可能会导致数据丢失的风险增加。
-
性能影响:半同步复制相对于同步复制来说对性能的影响较小,因为主数据库只需要等待至少一个从数据库的确认,而不是等待所有从数据库。这减少了等待时间,提高了写入性能。但与异步复制相比,半同步复制的性能可能稍微降低,因为主数据库需要等待确认消息。
如果有多个从,只要有一个从返回了确认,master就会继续往下运行了,如果ack确认包在10秒钟内没有送达,master会启用异步模式
配置
主
下载插件
root@(none) 10:25 mysql>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
临时修改
root@(none) 10:27 mysql>SET GLOBAL rpl_semi_sync_master_timeout = 1;
Query OK, 0 rows affected (0.00 sec)
root@(none) 10:27 mysql>SET GLOBAL rpl_semi_sync_master_enabled = 1;
Query OK, 0 rows affected (0.00 sec)
永久修改
[root@master-mysql ~]# vim /etc/my.cnf
[mysqld]
rpl_semi_sync_master_enabled=1 #添加
rpl_semi_sync_master_timeout=1000 #添加
刷新mysql服务
[root@master-mysql ~]# service mysqld restart
Shutting down MySQL............. SUCCESS!
Starting MySQL..... SUCCESS!
看是否开启半同步
root@(none) 10:33 mysql>SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
+----------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE |
+----------------------+---------------+
1 row in set (0.00 sec)
从
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
临时修改
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
永久修改
[mysqld]
rpl_semi_sync_slave_enabled=1
刷新服务
[root@slave-msql ~]# service mysqld restart
Shutting down MySQL..... SUCCESS!
Starting MySQL.... SUCCESS!
查看是否开启
root@(none) 11:55 mysql>SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
+----------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE |
| rpl_semi_sync_slave | ACTIVE |
+----------------------+---------------+
2 rows in set (0.00 sec)
同步复制(组复制)
https://www.cnblogs.com/kevingrace/p/10260685.html
MySQL的同步复制是一种数据复制策略,确保主数据库上的数据更改立即同步到一个或多个从数据库上。在同步复制中,当主数据库上的事务提交后,从数据库将立即应用相同的更改,以保持数据的一致性。
以下是MySQL同步复制的详细介绍:
- 配置主数据库:在主数据库上进行必要的配置,以启用二进制日志(binary logging)。这可以通过在主配置文件(如my.cnf)中设置以下参数来实现:
log_bin = /path/to/binlog
server_id = unique_server_id
其中,log_bin
参数指定二进制日志文件的路径,server_id
参数指定主数据库的唯一标识符。
- 配置从数据库:在每个从数据库上进行必要的配置,以使其能够复制主数据库的数据。可以使用
CHANGE MASTER TO
语句将从数据库配置为复制主数据库。以下是一个示例:
CHANGE MASTER TO
MASTER_HOST = 'master_hostname',
MASTER_USER = 'replication_user',
MASTER_PASSWORD = 'replication_password';
其中,master_hostname
是主数据库的主机名,replication_user
和replication_password
是用于复制的用户名和密码。
- 启动从数据库复制:在从数据库上启动复制进程,以开始从主数据库复制数据。可以使用
START SLAVE
语句启动从数据库复制。例如:
START SLAVE;
此命令将启动从数据库复制进程,并将开始从主数据库读取和应用二进制日志的数据。
-
数据复制:当主数据库上的事务提交后,它将被写入二进制日志。从数据库的复制进程将实时监视二进制日志,并将其中的更改应用到从数据库上,使其与主数据库保持一致。
-
监控和维护:在进行同步复制时,需要监控复制的状态和性能。可以使用MySQL提供的内置命令和工具(如
SHOW SLAVE STATUS
和mysqlbinlog
)来检查从数据库的复制状态、延迟和错误。
需要注意的是,同步复制对主数据库的性能有一定的影响,因为它要求主数据库等待从数据库应用复制更改的确认。如果从数据库的复制进程出现延迟或故障,可能会导致主数据库上的性能下降。因此,在设计和配置同步复制环境时,需要仔细评估主数据库的负载和复制的可靠性需求。
同步复制是一种常用的数据库复制策略,适用于要求数据一致性和高可靠性的应用程序。它确保在主数据库故障时可以快速切换到从数据库,以实现高可用性和容错性。
主主复制
MySQL的主主复制是一种数据复制策略,允许在两个或多个MySQL服务器之间进行双向的数据同步。在主主复制中,每个服务器既是主数据库又是从数据库,它们之间相互复制数据变更,以实现数据的一致性和冗余。
以下是MySQL主主复制的详细解释:
- 配置服务器:对于每个MySQL服务器,包括两个或多个将用于主主复制的服务器,需要进行必要的配置。这包括在每个服务器的配置文件(如my.cnf)中设置以下参数:
server_id = unique_server_id
log_bin = /path/to/binlog
其中,unique_server_id
是每个服务器的唯一标识符,log_bin
参数指定了二进制日志文件的路径。
-
启用二进制日志和复制:在每个服务器上启用二进制日志和复制功能。可以通过在每个服务器上的配置文件中设置上述参数来实现。
-
配置主数据库:选择其中一个服务器作为初始主数据库,并配置其他服务器作为从数据库。在主数据库上执行以下步骤:
- 设置其他服务器为从数据库:
CHANGE MASTER TO
MASTER_HOST = 'other_server_hostname',
MASTER_USER = 'replication_user',
MASTER_PASSWORD = 'replication_password';
其中,other_server_hostname
是其他服务器的主机名,replication_user
和replication_password
是用于复制的用户名和密码。
- 启动复制进程:
START SLAVE;
此命令将启动从数据库复制进程,并将开始从其他服务器读取和应用二进制日志的数据。
-
配置其他服务器:对于每个其他服务器,以同样的方式配置它们作为主数据库和从数据库。确保每个服务器都以其他服务器为主数据库,并启动复制进程。
-
数据复制:一旦配置完成并启动了复制进程,每个服务器都会实时复制其他服务器上的数据变更。这样,每个服务器既是主数据库又是从数据库,数据的更改将在所有服务器之间同步。
-
监控和维护:在主主复制环境中,需要定期监控复制的状态和性能,以确保数据的一致性和复制的可靠性。可以使用MySQL提供的内置命令和工具(如
SHOW SLAVE STATUS
和mysqlbinlog
)来检查复制状态、延迟和错误。
需要注意的是,主主复制需要谨慎处理数据冲突问题。由于数据在两个或多个服务器之间相互复制,可能会出现数据冲突的情况。例如,如果在两个服务器上同时修改了相同的数据行,可能会导致冲突。因此,在设计主主复制环境时,需要仔细考虑数据同步和冲突解决策略。
主主复制是一种高可用性和冗余的数据库复制策略,适用于需要实现数据冗余和故障转移的应用程序。它允许在多个服务器之间实现数据的双向同步,以提高系统的可用性和可靠性。
主主复制主键冲突问题解决方案:
2台主机都是master,业务数据同时往2台机器上写
机器的使用率会提升
https://www.jianshu.com/p/469279c1ad39
GTID
全局事务标识符GTID的全称为Global Transaction Identifier,是在整个复制环境中对一个事务的唯一标识。它是MySQL 5.6加入的一个强大特性,目的在于能够实现主从自动定位和切换,而不像以前需要指定文件和位置。
以前需要指定文件和位置 CHANGE MASTER TO MASTER_HOST='192.168.2.3', MASTER_USER='slave', MASTER_PASSWORD='123456', MASTER_PORT=3306, MASTER_LOG_FILE='master-mysql-bin.000001', MASTER_LOG_POS=154;
1、全局唯一,一个事务对应一个GTID
2、替代传统的binlog+pos复制;使用master_auto_position=1自动匹配GTID断点进行复制
3、MySQL5.6开始支持
4、在传统的主从复制中,slave端不用开启binlog;但是在GTID主从复制中,必须开启binlog
5、slave端在接受master的binlog时,会校验GTID值6、为了保证主从数据的一致性,多线程同时执行一个GTID
使用GTID复制时,主库上提交事务时创建事务对应的GTID,从库在应用中继日志时用GTID识别和跟踪每个事务。在启动新从库或因故障转移到新主库时可以使用GTID来标识复制的位置,极大地简化了这些任务。
工作原理
1、master更新数据时,会在事务前产生GTID,一同记录到binlog日志中。
2、slave端的i/o 线程将变更的binlog,写入到本地的relay log中。
3、sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录。
4、如果有记录,说明该GTID的事务已经执行,slave会忽略。
5、如果没有记录,slave就会从relay log中执行该GTID的事务,并记录到binlog。6、在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描
配置基于GTID的半同步主从复制
主
[root@master-mysql ~]# cat /etc/my.cnf
[mysqld_safe]
[client]
socket=/data/mysql/mysql.sock
[mysqld]
socket=/data/mysql/mysql.sock
port = 3306
open_files_limit = 8192
innodb_buffer_pool_size = 512M
character-set-server=utf8
#skip-grant-tables
#开启二进制日志
log-bin
#这是主从需要的
server-id =1
expire_logs_days=3
#开启半同步,需要提前安装半同步的插件
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000
#gtid功能
gtid-mode=ON
enforce-gtid-consistency=ON
[mysql]
auto-rehash
prompt=\u@\d \R:\m mysql>
在master上新建一个用户授权用户,给slave来复制二进制日志
grant replication slave on *.* to 'slave'@'192.168.2.%' identified by '123456';
flush privileges;
重启
[root@master-mysql mysql]# service mysqld restart
从
[root@mysql ~]# cat /etc/my.cnf
[mysqld_safe]
[client]
socket=/data/mysql/mysql.sock
[mysqld]
socket=/data/mysql/mysql.sock
port = 3306
open_files_limit = 8192
innodb_buffer_pool_size = 512M
character-set-server=utf8
#二进制文件
log_bin
server_id=2
#开启半同步,需要提前安装半同步的插件
rpl_semi_sync_slave_enabled=1
#从数据库将记录复制自主数据库的更改操作,这些更改将被写入从数据库的二进制日志。
log_slave_updates=ON
#gtid
gtid-mode=ON
enforce-gtid-consistency=ON
[mysql]
auto-rehash
prompt=\u@\d \R:\m mysql>
log_slave_updates=ON 让sql线程执行中继也产生二进制日志
以前slave机器配置了master的信息需要清除配置,*
stop slave;
reset slave all;
重启
[root@master-mysql mysql]# service mysqld restart
重新配置master信息
CHANGE MASTER TO MASTER_HOST='192.168.2.3',
MASTER_USER='slave',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
master_port=3306,
master_auto_position=1;
测试是否执行成功
在master机器上,进行增删操作就可了
Retrieved_Gtid_Set: 951033bf-1bea-11ee-a85d-000c299e81dd:1-3
Executed_Gtid_Set: 951033bf-1bea-11ee-a85d-000c299e81dd:1-3
这就代表配置成功了。