MYSQL8.0不停机搭建主从复制

从数据库会根据主库bin日志执行备份之后的sql

@raybon 已经进行了一波复现，完全没有遇到你的情况，从库启动并不是你说的这个逻辑，binlog是一个很大的文件（非常big）所以可能是你设置的这个文件尺寸太小，从你拷贝完数据到从库上开始恢复这个时间节点，主库已经划过了一整个的文件位了，自然就找不到报错了（这个只是我的猜测，也许还有其他的原因），

position只是标识当前正常记录的最后的二进制文件中的位置。pos一直在变化，但是并不代表你导出时候的那个pos已经不在了。只是告诉从库，你开始拷贝的时候要从这个指定的pos位置开始读取。所以你的情况更像是，binlog文件已经被刷新，原来的pos位置已经找不到了。才会报错

show variables like ‘max_binlog_size’;
你可以使用这个命令查看binlog文件的大小，超过这个尺寸之后就会刷新，自然就找不到原来的位置了

@raybon 现在我瞎鸡毛写了个完全不存在的位置，终于报错了

Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.000071' at 1020, the last event read from './mysql-bin.000071' at 123, the last byte read from './mysql-bin.000071' at 1039.'

@raybon 我进行了复现，现在简单说一下我的做法，以及结果。感觉确实是个很有意思的事情。

测试代码A：无事务环境下，密集循环写入，不过虽然密集，本质只占用了一个链接进程

$i = 1;
$DB = DB::connection("mysql_test");
while ($i < 100000) {
    $DB->table('album')->insert([
    'title'=>$i,
    'artist'=>123,
    'price'=>123
    ]);
$i++;
}
dd(1);

测试代码B：携带事务以及sleep的一个写入过程

$i = 1;
$DB = DB::connection("mysql_test");
$DB->beginTransaction();
while ($i < 1000) {
    $DB->table('album')->insert([
    'title'=>$i,
    'artist'=>123,
    'price'=>123
    ]);
$i++;
}
$DB->commit();
dd(1);

结果是A 和B 在主服务上面启动了10秒后再次开启从服务器都能正常开启，并且能获取主服务器的更新数据，并且开启事务的代码上面（事务中更新的数据两台服务器上面都看不见，事务提交后逐步更新到主从服务器），事务运行过程中再重新手动在目标表上面进行操作是能正常同步到从服务器上面的。

@raybon 一个极好的消息~

我通过flush binary logs; 刷新二进制文件复现了一个情况，不过这个情况还是因为（使用了重置命令，就是重新创建复制从服务的命令）

CHANGE MASTER TO MASTER_HOST='10.206.0.10',MASTER_USER='xxx',MASTER_PASSWORD='xxx',MASTER_LOG_FILE='xxx',MASTER_LOG_POS=xxx;

不过这个报错的本质是重复的数据日志写入（因为这些id号已经写过了）