本文的目的是介绍Mysqlbinlog无法删除(purge命令无法删除)的详细情况，特别关注mysql删除binlog启动不了的相关信息。我们将通过专业的研究、有关数据的分析等多种方式，为您呈现一个全

本文的目的是介绍Mysql binlog 无法删除(purge命令无法删除)的详细情况，特别关注mysql删除binlog 启动不了的相关信息。我们将通过专业的研究、有关数据的分析等多种方式，为您呈现一个全面的了解Mysql binlog 无法删除(purge命令无法删除)的机会，同时也不会遗漏关于06 : mysql 的 binlog 日志 和slow慢日志 详解、canal 1.1.1 发布，阿里 MySQL Binlog 增量订阅&消费组件、centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？、Docker 下 MySQL 主从三部曲之三：binlog 日志参数实战的知识。

• Mysql binlog 无法删除(purge命令无法删除)（mysql删除binlog 启动不了）
• 06 : mysql 的 binlog 日志 和slow慢日志 详解
• canal 1.1.1 发布，阿里 MySQL Binlog 增量订阅&消费组件
• centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？
• Docker 下 MySQL 主从三部曲之三：binlog 日志参数实战

Mysql binlog 无法删除(purge命令无法删除)（mysql删除binlog 启动不了）

06 : mysql 的 binlog 日志 和slow慢日志 详解

mysql 的 binlog 日志 和slow慢日志 详解

mysql一般常用的日志有三种：
1：error错误日志
2: binlog日志
3：slow日志

下面将详细解释这三种日志：

1、错误日志
记录MySQL启动或工作过程中，数据库状态信息,默认就是开启的，数据路径下$hostname.err。
也可以指定错误路径：
log_error=/var/log/mysql3306.log

2、二进制binlog日志
（1）他记录了什么？
记录了所有的数据库修改类的命令：
DDL
DCL
DML

（2）二进制日志记录格式：
DDL：直接以语句模式（statement）
DCL：直接以语句模式（statement）
DML：语句模式（statement）、行模式（rows，推荐模式）、混合模式（mixed）

注：对事务性语句，只会记录已提交事务的二进制日志。

（3）binlog的作用

备份 ---- 恢复
主从 ---- 复制

（4）二进制日志格式有哪些？
statement：语句模式
row：行模式，即数据行的变化过程
mixed：以上两者的混合模式。

我们企业推荐使用row模式，5.6中默认模式statement，5.7中默认row
两种模式有什么优缺点？
statement:
优点：简单明了，容易被看懂，就是sql语句，记录时需要更小的磁盘空间
缺点：记录不够严谨

row 模式：
优点：记录更加严谨
缺点：有可能需要更多的磁盘空间，不太容易读懂

（5）二进制日志配置(一般会和数据文件分开 )
mkdir -p /data/mysql
chown -R mysql.mysql /data/mysql

/data/mysql要事先创建好，有权限。

vim /etc/my.cnf
log_bin=/data/mysql/mysql-bin #打开二进制日志，并设置位置和文件名前缀
binlog_format=row #二进制日志格式设置为row
重启MySQL生效。
/etc/init.d/mysqld restart

(6)binlog常用查询和使用命令：
ls -l /data/mysql/
查询什么？
二进制日志内容：
1、二进制日志对DDL、DCL以语句形式记录
2、DML语句记录是已经commit成功的事务（begin dml1 dml2 commit）
3、binlog以event为最小单元进行记录
对于DDL、DCL类语句，一条语句就是一个event（事件）
对于DML会将事务中每个涉及到的命令和变更，拆解为多个event来记录
二进制日志内容查看：
show binary logs; ---->看所有的二进制日志
show master status ; ---->看当前在使用的二进制日志文件
show binlog events in ''mysql-bin.000001''; ---->查看1号二进制日志事件信息
show binlog events in ''mysql-bin.000004'' limit 5;
看前五行(binlog里面一条语句和一条事务都是一个事件)
------
fulsh logs; 切割binlog日志
show variables like ''binlog_format''; 查看binlog日志格式
mysqlbinlog mysql-bin.log 查看binlog内容
示例：
mysql> create database ygirl;
mysql> show binlog events in ''mysql-bin.000003'';
mysql> create database ygirl1;
mysql> show binlog events in ''mysql-bin.000003'' limit 5;

二进制日志内容分析
二进制日志是以event方式记录。
event的生命周期 开始位置点 -------> 结束位置点
start-position stop-postion

导出binlog日志：
mysqlbinlog /data/mysql/mysql-bin.000003>/tmp/binlog.sql

将Row格式记录的DML语句进行翻译：
mysqlbinlog --base64-output=DECODE-ROWS -vvv /data/mysql/mysql-bin.000003

截取binlog，开始点和结束点。binlog 文件里面的at:23213 数字就是事件位置点
mysqlbinlog --start-postion=689470 --stop-postion=689835 /data/mysql/mysql-bin.000003

如何截取二进制日志内容：
案例:
1、备份二进制日志
flush logs; 刷新新的二进制日志
打包压缩备份不再被mysql使用的而进制日志

2、数据损坏恢复（对数据损坏，80%以上都是人为的）
（1）数据库损坏情况
物理损坏：
物理磁盘坏
格式化
rm -rf
mv
逻辑损坏：
drop
delete
update
truncate

（2）模拟删库，binlog恢复
drop database world;
只获取和world数据库有关的binlog语句
mysqlbinlog -d world --start-position=420 /data/mysql/mysql-bin.000003 >/tmp/world.sql
mysql> set sql_log_bin=0;（临时关闭当前连接窗口的二进制binlog记录）
mysql> source /tmp/world.sql 导入binlog
mysql> set sql_log_bin=1; （恢复binlog记录）
其实不设置也无所谓，窗口退出就失效了。

（7）二进制日志切割的几种方法：
1: flush logs; mysql命令行执行，刷新 binlog 切割。
2: 在[mysqld]节点中增加如下
max_binlog_size = 500M ：bin log日志每达到设定大小后，会使用新的bin log日志。如mysql-bin.000002达到500M后，创建并使用mysql-bin.000003文件作为日志记录。
3: F 大F，需要在命令行执行

（8）二进制日志清理方法：
设置日志过期时间，自动清理策略
SET GLOBAL expire_logs_days = 7; 命令行生效

vim /etc/my.cnf
expire_logs_days = 7
注：按照备份策略进行清理，一般是按照全备的周期
一般企业都是保留近期两个完整的全备。所以过期时间至少设置为2个全备周期。
条件允许的话，能多保留则多保留。

根据天数清理
PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day;

根据文件名删除日志
PURGE BINARY LOGS TO ''mysql-bin.000010'';

删除所有二进制日志，从000001开始重新记录。
reset master;

---------------------------------------
3、slow_log(慢日志)

（1）记录查询较慢SQL语句的日志文件。
（2）配置参数：
slow_query_log=1 #开启慢日志开关
slow_query_log_file=/data/mysql/slow.log #定义日志位置和名字
long_query_time=0.1 #定义慢查询时间阈值，超过0.1s的语句记录慢日志
log_queries_not_using_indexes #没走索引的查询，记录慢日志

重启mysql生效：

进入数据库：查看参数是否生效
mysql> show variables like ''long_query_time'';

（3）模拟慢查询语句
create table city1 select * from city; 把city表查询到的数据导入到新创建的city1里面
去查看slow.log 会发现里面有这条的记录

insert into city1 select * from city1; 把city1表查询到的数据插入到city1里面
insert into city1 select * from city1;
insert into city1 select * from city1;
commit; （我在配置文件里面关闭了自动事务提交，所以这边需要执行手动commit）
去查看slow.log 会发现里面有这条的记录

一堆查询:where条件 满足countrycode=''CHN'' 和 name=''shanghai'';
select * from city1 where countrycode=''CHN'' and name=''shanghai'';
select * from city1 where countrycode=''CHN'' and name=''shanghai'';
select * from city1 where countrycode=''CHN'' and name=''shanghai'';
因为没有索引，走的是全表扫描查询。所以耗时会长，表越大查询越慢
我们添加一下索引：
alter table city1 add index idx(countrycode,name);
在查询会发现快很多很多。
select * from city1 where countrycode=''CHN'' and name=''shanghai'';
查看详细的查询信息：是否走索引了
explain select * from city1 where countrycode=''CHN'' and name=''shanghai'';
----------------------------------------------------------------------------------
mysqldumpslow:命令

mysqldumpslow -s c -t 10 /data/mysql/slow.log 显示出top10个慢查询语句,
-s c 代表慢查询语句，按出现的次数排序
-t 10 代表top 前10个语句
mysqldumpslow -s t -t 10 /data/mysql/slow.log 按语句执行时间来排序，

-----------------------------------------
扩展分析slow日志工具：

yum -y install perl perl-devel perl-Time-HiRes perl-DBD-MySQL

然后去官网下载这个工具包，解压
tar xf percona-toolkit-2.2.20.tar.gz && cd percona-toolkit-2.2.20/bin
yum -y install perl-Digest-MD5
分析内容会很详细：
./pt-query-diagest /data/mysql/slow.log

#mysql自带的分析慢查询命令
mysqlslap

------------------慢 查询优化思路----------------------

解决的思路：
1、开启慢日志功能，设置慢日志记录标准，将慢查询时间定为0.1秒，将不走索引语句记录下来。
2、收集3天慢日志，进行分析
3、使用pt-query-diagest工具分析3天内的慢日志
4、找到运行次数较多并执行时间较长的SQL，找到此类语句5条。
5、按照一定的优先级，分析SQL语句的执行计划，其中3条，是语句不够规范导致的慢，将语句反馈给开发。
6、其中发现原因2条语句是因为索引建立不合理，进行索引调整。

--------------------附上/etc/my.cnf 目前配置----------------------

[mysqld]
basedir=/application/mysql
datadir=/application/mysql/data
socket=/application/mysql/data/mysql.sock
server_id=3306
port=3306
log_error=/application/mysql/data/mysql.log
log_bin=/application/mysql/data/mysql-bin
binlog_format=row
default-storage-engine=InnoDB   #使用innoDB引擎
autocommit=0                              # 关闭自动提交事务
max_binlog_size = 500M
expire_logs_days = 15
slow_query_log=1
slow_query_log_file=/application/mysql/data/slow.log
long_query_time=0.1
log_queries_not_using_indexes

[client]
socket=/application/mysql/data/mysql.sock

--------------------------------------------------------------------------------------------

canal 1.1.1 发布，阿里 MySQL Binlog 增量订阅&消费组件

功能新增

1. 原生支持 RocketMQ 消息投递 #695 【Canal Kafka QuickStart】

2. 原生支持 hbase 的数据同步 #849 ClientAdapter

3. 新增 c#/go 多语言客户端的支持

• canal java 客户端: https://github.com/alibaba/canal/wiki/ClientExample

• canal c# 客户端开源项目地址： https://github.com/CanalSharp/CanalSharp

• canal go 客户端开源项目地址： https://github.com/CanalClient/canal-go

4. MQ 消息投递支持按 pk hash 到多个分区 partition ( Kafka/RocketMQ 均支持) #958

小需求&bugfix

1. 修复单核环境下的 canal 启动异常问题 #873

2. 修复 parse 并行解析模式 gtid 的并发问题 #881

3. java client 内聚 guava 打包，解决和外部系统的版本冲突问题 #912

4. 升级 proto2 为 proto3(3.6.1)，支持更多的跨语言能力

5. 支持配置中数据库密码加密处理 #990

6. 并行解析下，数据库一直连不上导致 OOM 异常(线程数泄漏,出现暴涨) #968

7. mysql set 类型8值情况解析越界 bugfix otter#617

8. 支持 otter 使用 canal 的新特性，比如 rds ak/sk 配置、tsdb 配置

9. 修复 docker 部署 canal-server 无法使用 docker-restart 命令 #1001

10. 修复 mysql bit(8) 类型8值情况解析越界 bugfix

11. tablemeta tsdb 数据增加过期清理能力 #1047

发行地址：https://github.com/alibaba/canal/releases

canal 是阿里巴巴 MySQL 数据库 Binlog 的增量订阅&消费组件。

早期，阿里巴巴 B2B 公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需求。不过早期的数据库同步业务，主要是基于 trigger 的方式获取增量变更，不过从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务，从此开启了一段新纪元。

ps. 目前内部版本已经支持 mysql 和 oracle 部分版本的日志解析，当前的 canal 开源版本支持5.7及以下的版本(阿里内部 mysql 5.7.13, 5.6.10, mysql 5.5.18 和 5.1.40/48 )

基于日志增量订阅&消费支持的业务：

1. 数据库镜像

2. 数据库实时备份

3. 多级索引 (卖家和买家各自分库索引)

4. search build

5. 业务 cache 刷新

6. 价格变化等重要业务消息

centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？

centos7 设置 mysql 自启动的配置文件中

[Unit]
Description=MySQL Server
Documentation=man:mysqld(8)
Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.html
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target

[Service]
User=mysql
Group=mysql
ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf
LimitNOFILE = 5000
#Restart=on-failure
#RestartPreventExitStatus=1
#PrivateTmp=false

这里的

[Service]

User=mysql

Group=mysql，

user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？还是其他呢？

Docker 下 MySQL 主从三部曲之三：binlog 日志参数实战

本章是《Docker 下 MySQL 主从三部曲》的终篇，前面的章节我们能够制作镜像来搭建主从同步环境，本章我们来观察 binlog 参数 MASTER_LOG_POS；

原文地址：https://blog.csdn.net/boling_cavalry/article/details/79782008

前文链接

1. 《Docker 下 MySQL 主从三部曲之一：极速体验》；
2. 《Docker 下 MySQL 主从三部曲之二：细说镜像制作》；

关于从库同步的设置

在设置从库同步的时候一般会使用以下 SQL：

CHANGE MASTER TO MASTER_HOST=''172.17.0.2'', \
MASTER_USER=''rep'', \
MASTER_PASSWORD=''888888'', \
MASTER_LOG_FILE=''mysql-bin.000001'', \
MASTER_LOG_POS=745;

今天我们的实战和上面的 MASTER_LOG_FILE、MASTER_LOG_POS 两个参数有关；

第一个问题

上一章制作从库镜像时并未设置 MASTER_LOG_FILE 和 MASTER_LOG_POS，但是之前的文章《Docker 下手工配置 MySQL 主从》中却又设置了这两个参数，那么在设置主从同步的时候，究竟该不该设置这两个参数呢？

前面两章实战我们已经验证过了，不设置这两个参数并不会影响主从同步，所以可以不设置，那么就剩下一个问题：设置了 MASTER_LOG_FILE 和 MASTER_LOG_POS 有什么影响？

参数 MASTER_LOG_FILE

在 master 容器的 MySQL 命令行执行 show master status：

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

如上所示，bin log 文件名为 mysql-bin.000003，在 /etc/mysql/mysql.conf.d/mysqld.cnf 中定义的文件路径如下：

[mysqld]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
#log-error      = /var/log/mysql/error.log
# By default we only accept connections from localhost
#bind-address   = 127.0.0.1
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

根据以上配置信息，我们在 /var/lib/mysql 目录下找到了 bin log 文件 mysql-bin.000003，如下：

root@ae594a28192d:/var/lib/mysql# pwd
/var/lib/mysql
root@ae594a28192d:/var/lib/mysql# ls -al
total 191468
drwxr-xr-x  5 mysql mysql     4096 Apr  2 01:12 .
drwxr-xr-x 19 root  root      4096 Mar 14 07:47 ..
-rw-r-----  1 mysql mysql       56 Apr  2 01:12 auto.cnf
-rw-------  1 mysql mysql     1675 Apr  2 01:12 ca-key.pem
-rw-r--r--  1 mysql mysql     1107 Apr  2 01:12 ca.pem
-rw-r--r--  1 mysql mysql     1107 Apr  2 01:12 client-cert.pem
-rw-------  1 mysql mysql     1675 Apr  2 01:12 client-key.pem
-rw-r-----  1 mysql mysql     1353 Apr  2 01:12 ib_buffer_pool
-rw-r-----  1 mysql mysql 50331648 Apr  2 01:13 ib_logfile0
-rw-r-----  1 mysql mysql 50331648 Apr  2 01:12 ib_logfile1
-rw-r-----  1 mysql mysql 79691776 Apr  2 01:13 ibdata1
-rw-r-----  1 mysql mysql 12582912 Apr  2 01:13 ibtmp1
drwxr-x---  2 mysql mysql     4096 Apr  2 01:12 mysql
-rw-r-----  1 mysql mysql      177 Apr  2 01:12 mysql-bin.000001
-rw-r-----  1 mysql mysql  3039401 Apr  2 01:12 mysql-bin.000002
-rw-r-----  1 mysql mysql      154 Apr  2 01:12 mysql-bin.000003
-rw-r-----  1 mysql mysql       57 Apr  2 01:12 mysql-bin.index
drwxr-x---  2 mysql mysql     4096 Apr  2 01:12 performance_schema
-rw-------  1 mysql mysql     1675 Apr  2 01:12 private_key.pem
-rw-r--r--  1 mysql mysql      451 Apr  2 01:12 public_key.pem
-rw-r--r--  1 mysql mysql     1107 Apr  2 01:12 server-cert.pem
-rw-------  1 mysql mysql     1675 Apr  2 01:12 server-key.pem
drwxr-x---  2 mysql mysql    12288 Apr  2 01:12 sys
root@ae594a28192d:/var/lib/mysql# 

设置同步时，若 MASTER_LOG_FILE 有误会怎么样？来试试：
1. 进入 MySQL 第一从库容器，再进入 MySQL 命令行；
2. 执行 stop slave; 停止同步；
3. 执行以下 SQL 重新设置同步参数，其中 MASTER_LOG_FILE 已被改成一个不存在的文件名 “mysql-bin.999999”：

CHANGE MASTER TO MASTER_HOST=''masterhost'', \
MASTER_USER=''rep'', \
MASTER_PASSWORD=''888888'', \
MASTER_LOG_FILE=''mysql-bin.999999'', \
MASTER_LOG_POS=154;

4. 执行 start slave; 开始同步；
5. 执行 show slave status\G 查看同步状态，发现”Last_IO_Error” 字段的值如下，提示找不到 binlog 文件：

 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ''Could not find first log file name in binary log index file''

6. 此时在主库的 MySQL 命令行执行 SQL 新增一条记录：insert into test_table(name) values (‘tom’);；
7. 回到第一从库查看 test_table 表，发现数据没有同步过来；
8. 去第二从库查看 test_table 表，数据同步正常：

小结：MASTER_LOG_FILE 的值与主库同步的 binlog 名不一致会导致同步失败；

查看 binlog 文件

接下来看看 MASTER_LOG_POS 参数的作用，我们把之前的容器全部清除再重新来验证：
1. 在 docker-compose.yml 文件所在目录下执行 docker-compose down，将一主二从容器全部删除；
2. 在 docker-compose.yml 文件所在目录下执行 docker-compose up -d，像《Docker 下 MySQL 主从三部曲之一：极速体验》一样重新创建一主二从；
3. 进入第一从库，在 MySQL 命令行执行 stop slave;，将主从同步停止；
4. 在 MySQL 主库的命令行执行以下命令，创建数据库、表、新增记录：

create database test001;

use test001;

CREATE TABLE `test_table` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into test_table(name) values (''jerry'');

5. 执行 show master status;，查出 binlog 文件名为 mysql-bin.000003；
6. 推出 MySQL 命令行，执行 mysqlbinlog /var/lib/mysql/mysql-bin.000003 > ~/mysql-bin.000003.txt 将 binlog 文件转成可读的文本文件；
7. 打开文件 ~/mysql-bin.000003.txt，看到如下内容：

SET @@session.collation_database=DEFAULT/*!*/;
create database test001
/*!*/;
# at 322
#180402 12:37:52 server id 1  end_log_pos 387 CRC32 0xa2118048  Anonymous_GTID  last_committed=1        sequence_number=2       rbr_only=no
SET @@SESSION.GTID_NEXT= ''ANONYMOUS''/*!*/;
# at 387
#180402 12:37:52 server id 1  end_log_pos 628 CRC32 0x4eb6b868  Query   thread_id=4     exec_time=1     error_code=0
use `test001`/*!*/;
SET TIMESTAMP=1522672672/*!*/;
CREATE TABLE `test_table` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
/*!*/;
# at 628
#180402 12:37:57 server id 1  end_log_pos 693 CRC32 0x37e9fbe9  Anonymous_GTID  last_committed=2        sequence_number=3       rbr_only=ye
s
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= ''ANONYMOUS''/*!*/;
# at 693
#180402 12:37:57 server id 1  end_log_pos 768 CRC32 0x0a4b387b  Query   thread_id=4     exec_time=0     error_code=0
SET TIMESTAMP=1522672677/*!*/;
BEGIN
/*!*/;
# at 768
#180402 12:37:57 server id 1  end_log_pos 827 CRC32 0x45fec29f  Table_map: `test001`.`test_table` mapped to number 108
# at 827
#180402 12:37:57 server id 1  end_log_pos 874 CRC32 0x620435ef  Write_rows: table id 108 flags: STMT_END_F

BINLOG ''
JSTCWhMBAAAAOwAAADsDAAAAAGwAAAAAAAEAB3Rlc3QwMDEACnRlc3RfdGFibGUAAgMPAiwBAp/C
/kU=
JSTCWh4BAAAALwAAAGoDAAAAAGwAAAAAAAEAAgAC//wBAAAABQBqZXJyee81BGI=
''/*!*/;
# at 874
#180402 12:37:57 server id 1  end_log_pos 905 CRC32 0x6128e936  Xid = 29
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= ''AUTOMATIC'' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file

从上述内容可以看到，每次写入操作之后都会有个# at xxx 这样的标记，这就是 MASTER_LOG_POS 对应的数字；
8. 将上面的几个关键点整理成下面的表格：

修改 MASTER_LOG_POS

接下来我们修改 MASTER_LOG_POS 参数试试：
1. 进入第一从库容器的 MySQL 命令行；
2. 执行下面的 SQL，令 MASTER_LOG_POS 等于 628，也就是不包含创建数据库和创建表的 binlog 内容：

CHANGE MASTER TO MASTER_HOST=''masterhost'', \
MASTER_USER=''rep'', \
MASTER_PASSWORD=''888888'', \
MASTER_LOG_FILE=''mysql-bin.000003'', \
MASTER_LOG_POS=628;

3. 进入第一从库，在 MySQL 命令行执行 start slave;，将主从同步启动；
4. 执行 show slave status\G 查看同步状态，看到 Last_SQL_Error 字段的内容如下：

Last_SQL_Error: Error executing row event: ''Table ''test001.test_table'' doesn''t exist''

如上所示，MASTER_LOG_POS 参数指定的 AT 数字之后的 binlog 才会被执行，之前的是不执行的；
5. MySQL 命令行执行 stop slave;，将主从同步停止；
6. 执行下面的 SQL，令 MASTER_LOG_POS 等于 154，也就是创建数据库之前的位置：

CHANGE MASTER TO MASTER_HOST=''masterhost'', \
MASTER_USER=''rep'', \
MASTER_PASSWORD=''888888'', \
MASTER_LOG_FILE=''mysql-bin.000003'', \
MASTER_LOG_POS=154;

7. MySQL 命令行执行 start slave;，将主从同步启动；
8. 查看同步状态，已经正常，再去查数据库数据，也已经同步过来了：

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test001            |
+--------------------+
5 rows in set (0.00 sec)

mysql> use test001;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from test_table;
+----+-------+
| id | name  |
+----+-------+
|  1 | jerry |
+----+-------+
1 row in set (0.00 sec)

到这里，对 MASTER_LOG_POS 参数的实战就结束了，该参数与 binlog 中的 “at” 标记对应，如果设置不当，会导致前面的 SQL 操作丢失，在遇到有依赖的同步操作时就会有问题；

至此，Docker 下 MySQL 主从三部曲就全部结束了，希望能够给您的 Docker 实战带来一些参考，助您做出更实用的镜像；

本文分享 CSDN - 程序员欣宸。
如有侵权，请联系 support@oschina.cn 删除。
本文参与 “OSC 源创计划”，欢迎正在阅读的你也加入，一起分享。

关于Mysql binlog 无法删除(purge命令无法删除)和mysql删除binlog 启动不了的问题我们已经讲解完毕，感谢您的阅读，如果还想了解更多关于06 : mysql 的 binlog 日志 和slow慢日志 详解、canal 1.1.1 发布，阿里 MySQL Binlog 增量订阅&消费组件、centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？、Docker 下 MySQL 主从三部曲之三：binlog 日志参数实战等相关内容，可以在本站寻找。