乐趣区

关于mysql:线上环境mysql主从同步的搭建过程

之前搭建过一套主从同步的 mysql 集群,然而是基于新数据库,而这次线上环境要升级成主从同步的集群,记录一下降级过程和两头遇到的各种问题。

因为是间接对线上数据库进行批改,因而要保障对线上环境造成尽量小的影响。所以把之前的数据库当作主数据库,这样相应的服务不必批改配置文件。要做的就是装置一个从数据库并且实时同步主数据库的改变。

如果两个库在同一个服务器的话则装置 mysql 时须要扭转其端口。

如果在另一个服务器装置的话留神查看并卸载旧的 mysql。

首先装置从库:

装置 mysql

下载软件包:

wget https://repo.mysql.com//mysql80-community-release-el7-1.noarch.rpm

本地装置:

yum localinstall mysql80-community-release-el7-1.noarch.rpm

装置 mysql:

yum install mysql-community-server

设为开机启动:

systemctl enable mysqld

systemctl daemon-reload

启动 mysql:

systemctl start mysqld

以上步骤就装置好 mysql8 了。

获取 mysql 的长期明码:

grep 'temporary password' /var/log/mysqld.log

登录 mysql:

mysql -uroot -p

会提醒输出明码,输出之前获取的长期明码即可登录。

此时须要批改 mysql 的明码,要不然之后的步骤也会强制提醒你须要批改明码:

ALTER USER 'root'@'localhost' IDENTIFIED BY '121b33dAj934J1^Sj9aa';

mysql8 默认对明码的强度有要求,须要设置简单一点,要不然也会提醒谬误。

刷新配置:

FLUSH PRIVILEGES;

对于主服务器的相干配置

设置 server-id 值并开启 binlog 参数 依据 mysql 的同步原理:关键因素就是 binlog 日志。编辑 /etc/my.cnf 配置文件,批改和增加相干参数。

vi /etc/my.cnf

[mysqld]
# 同一局域网内留神要惟一
server-id = 1
log-bin = mysql-bin
relay_log 配置中继日志
relay_log=edu-mysql-relay-bin

批改配置后须要重启能力失效:

service mysqld restart

重启后进入 mysql:

mysql -u root -p

在 master 数据库创立数据同步用户,授予用户 slave REPLICATION SLAVE 权限和 REPLICATION CLIENT 权限,用于在主从库之间同步数据。

CREATE USER 'slave'@'%' IDENTIFIED BY '@#$Rfg345634523rft4fa';

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';

语句中的 % 代表所有服务器都能够应用这个用户,如果想指定特定的 ip,将 % 改成 ip 即可。

主数据库须要重启一次,然而工夫十分短,如果对服务可用性十分高的服务要提前做好筹备。

因为主从同步开启必须确保须要同步的库数据完全一致,因而须要先备份主数据库,然而备份时不能有新数据的退出,所以须要给主库加一个读锁而后备份,这个过程继续的工夫依赖于数据库中数据量的多少,像咱们这个库有千万级的数据,备份工夫花了几十秒,在这几十秒的工夫里用户的读操作不受影响,然而不能写入。

备份主库

对主数据库锁表只读: 注:锁表会影响业务,请审慎解决 mysql>flush tables with read lock;

对主数据库备份:

mysqldump -uroot -p --databases doctor quartz | gzip >/backup/mysql_bak.$(date +%F)sql.gz

这个命令会备份 doctor 库和 quartz 库并且压缩,而后保留在 /back/ 文件夹下并以日期结尾。

留神:

这里过后遇到了一个大坑,最开始执行的备份命令是:

mysqldump -uroot -pmysql -A -B |gzip >/backup/mysql_bak.$(date +%F)sql.gz

(注:- A 示意备份所有库,- B 示意减少 user DB 和 drop 等参数(导库时会间接笼罩所有的)。)

在正式上从库导入数据后没问题,然而一旦把从库的主从同步配置改了之后 mysql 就起不来了,而这个命令在测试环境是没问题的,然而还是倡议把须要同步的库一个一个列出来,避免出现奇怪的问题。

记录地位

主库备份实现之后须要记录以后的地位:

show master status;

+———————-+———-+————–+——————+——————-+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+———————-+———-+————–+——————+——————-+
| edu-mysql-bin.000002 |   22361 |             | mysql           |                   |
+———————-+———-+————–+——————+——————-+

记下 File 和 Position 之后就能解锁主库了:

unlock tables;

到这里之后就没主库什么事了。

从库的配置

导入数据

把主库备份的 mysql 数据迁徙到从库:

scp -P 8523 /backup/mysql_bak.2022-07-17sql.gz root@11.11.111.66:/backup/mysql_bak.2022-07-17sql.gz

如果不想用 scp 命令能够手动复制粘贴数据过来,然而速度真的慢很多,传输之前要建好文件夹。

解压:gzip -d mysql_bak.2022-07-17sql.gz

导入数据。

在从 my.cnf 配置中新增:

mysqld]
## 设置 server_id, 留神要惟一
server-id=101
## 开启二进制日志性能,以备 Slave 作为其它 Slave 的 Master 时应用
log-bin=mysql-slave-bin
## relay_log 配置中继日志
relay_log=edu-mysql-relay-bin

批改配置后须要重启能力失效:

service mysql restart

重启之后进入 mysql:

mysql -uroot -p

change master to master_host='111.11.0.2', master_user='slave', master_password='@#$Rfg345634523rft4fa', master_port=3306, master_log_file='mysql-bin.000001', master_log_pos= 2830, master_connect_retry=30;

master_host:Master 的地址

master_port:Master 的端口号

master_user:用于数据同步的用户

master_password:用于同步的用户的明码

master_log_file:指定 Slave 从哪个日志文件开始复制数据,即上文中提到的 File 字段的值

master_log_pos:从哪个 Position 开始读,即上文中提到的 Position 字段的值

master_connect_retry:如果连贯失败,重试的工夫距离,单位是秒,默认是 60 秒

在从 mysql 中查看主从同步状态:

show slave status \G;

此时的 SlaveIORunning 和 SlaveSQLRunning 都是 No,因为咱们还没有开启主从复制过程。

开启主从复制:

start slave;

再次查看同步状态:

show slave status \G;

SlaveIORunning 和 SlaveSQLRunning 都是 Yes 阐明主从复制曾经开启。

实践上此时应该曾经胜利了,然而很道歉咱们每一次在这里都会卡住。

查看日志能够看到主从连贯失败,这是因为 mysql8 非凡的明码机制造成的,在最开始咱们在主数据库中建了一个用户用于主从同步,问题就出在这个用户的明码上,给这个用户改一下明码就行了。

ALTER USER 'slave'@'%' IDENTIFIED WITH mysql_native_password BY '@#$Rfg345634523rft4fa';

目前只有这个命令能失效,其余的都不能失效。把明码再笼罩一次,等超时工夫一过,就主动连贯上了。

退出移动版