共计 2925 个字符,预计需要花费 8 分钟才能阅读完成。
对运行一段时间的数据库做主从复制
序言:前几天对运行一段时间且 未开启 bin-log的 MySQL 数据库做了主从同复制,特此将具体操作步骤与阐明记录下来。留神本次同步 未应用 GTID进行主从复制,配置中应用 通配符 ,做到了只 同步特定名称的表,
主从数据库版本:二者都是 MySQL5.7
1. 主数据库配置,开启 bin-log,并重启数据库
先编辑主数据库的配置文件,我的数据库配置文件门路是:/etc/my.cnf。不要遗记先备份,以防配置出错。
cp /etc/my.cnf /etc/my.cnf.bak
vim /etc/my.cnf
次要配置内容如下,我已做了具体阐明:
server-id=234 # 主从集群中惟一,不要反复,我应用的 ip 地址后 4 位
binlog-do-db=master_slave_test # 须要同步的数据库
binlog-ignore-db=mysql # 无需开启 bin-log 的数据库
log_bin=mysql-bin # 启用 bin-log
master_info_repository=TABLE # 在从库中创立表,记录 master 的状态
relay_log_info_repository=TABLE # 在从库中创立表,记录同步的地位信息
relay_log_recovery=ON # 从库意外宕机重启,能够立刻复原到未执行的 sql 语句的地位
重启主数据库
systemctl restart mysqld
2. 从数据库配置,指定要同步的数据库,并重启数据库
server-id=167
slave-skip-errors=all # 跳过主从同步中遇到的所有谬误号,继续执行前面的 sql
replicate_do_db=master_slave_test # 须要复制的数据库
replicate_wild_do_table=master_slave_test.%table% # 须要复制的数据库中的表,应用通配符匹配含有‘table’字样的表
slave-parallel-type=LOGICAL_CLOCK # 并行复制
slave-parallel-workers=4 # slave 线程数
master_info_repository=TABLE # 在从库中创立表,记录 master 的状态
relay_log_info_repository=TABLE # 在从库中创立表,记录同步的地位信息
relay_log_recovery=ON # 从库意外宕机重启,能够立刻复原到未执行的 sql 语句的地位
重启从数据库
systemctl restart mysqld
3. 主库导出数据
在主库中,应用 mysqldump 工具将未开启 bin-log 之前的数据导出并压缩。
mysqldump -uroot -P3317 -p --single-transaction --master-data=2 --databases 数据库 1 --tables table 表名 1 table 表名 2 >master_slave_test.sql
gzip master_slave_test.sql
其中:
- –single-transaction:不锁表,同时保障 dump 的数据的一致性。
- –master-data:指定 = 1 时,会在导出的 sql 文件中减少一句 CHANGE MASTER TO MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS=1565461;,当在从库导入时,会执行那句 sql。咱们在从库开启主从时,须要手动写具体的 change 语句,所以不心愿在从库执行那句 sql,然而又须要获取 bin-log 的地位信息,所以指定 =2,即在导出的 sql 文件中将其正文。
当数据量十分大时,能够应用 nohup 工具,在后盾执行 mysqldump,具体操作如下:
nohup mysqldump -uroot -P3317 -p --single-transaction --master-data=2 --databases 数据库 1 --tables table 表名 1 table 表名 2 >master_slave_test.sql
(回车输出数据库明码)
ctrl+ z 中断
输出 bg 命令后盾运行
4. 从库导入数据
登录从库所在服务器,将.sql 文件拷贝过去,并且解压缩。
scp -P 22 -l 10000 zhengyuchuan@10.10.8.103:/data/backup/master_slave_test.sql.gz .
gzip -d master_slave_test.sql.gz
其中:
- -P:指定 ssh 登录的端口
- -l:限度 scp 带宽,以防对其余业务产生影响。这里限度到大略为 1M 左右
解压缩实现后,在从库导入数据。导入数据之前,首先在从库创立 master_slave_test 数据库。
create database master_slave_test charset=utf8mb4;
exit;
而后导入数据。
mysql -P3317 -uroot -p master_slave_test <master_slave_test.sql
同样的,也能够应用 nohup 工具让 scp 过程或者导入数据过程在后盾运行。
5. 主数据库创立用于从库同步的账号,并赋予同步权限
grant replication slave on *.* to 'slave_test'@'%' identified by '你的明码';
6. 从数据库开始同步;
CHANGE MASTER TO MASTER_HOST='10.10.8.103', MASTER_PORT=3317, MASTER_USER='slave_test', MASTER_PASSWORD='你的明码', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=489038 for channel 'master_slave_test';
其中:
- MASTER_HOST:主数据库的 ip
- MASTER_PORt:主数据库的登录端口
- MASTER_USER:方才在主数据创立的用于同步的账号
-
MASTER_LOG_FILE 与 MASTER_LOG_POS:能够通过.sql 文件查看,在前 50 行就能够看到。
head -50 master_slave_test.sql
- channel:指定通道,当前可能会同步多个库,这样方便管理。
开启 slave:
start slave for channel 'master_slave_test';
查看主从同步状态:
show slave status \G;
我这里拿出几项参数,留神其中 IO_Thread 与 SQL_Thread,两项都为 Yes,才示意,同步状态失常。如果有谬误,则显示 No 或 Connecting,而上面的 IO_Error 或 SQL_Error 会显示出具体的错误信息。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: 73894796
Relay_Log_Space: 73895318
Seconds_Behind_Master: 0
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
正文完