docker办公系统 docker for window

1. 拉取镜像

docker pull mysql:5.7.30

2. MySQL主从配置

2.1. 启动容器

2.1.1. 启动主MySQL容器

docker run -d --name mysql-master -p 13306:3306 -v D:/docker/mysql/master/log:/var/log/mysql -v D:/docker/mysql/master/data:/var/lib/mysql -v D:/docker/mysql/master/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=root  mysql:5.7.30

2.1.2. 启动从MySQL容器

docker run -d --name mysql-slave1 -p 13307:3306 -v D:/docker/mysql/slave1/log:/var/log/mysql -v D:/docker/mysql/slave1/data:/var/lib/mysql -v D:/docker/mysql/slave1/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=root mysql:5.7.30

2.2. 配置

2.1.1. 主MySQL配置

设置一个复制使用的账户，并授予 REPLICATION SLAVE 权限。
如下：创建一个复制用户 rep1，可以从 所有主机进行连接：

grant replication slave, replication client on *.* to 'repl'@'%' identified by '123456';
flush privileges;
--查看是否成功
select user,host from mysql.user;

--查看主服务器上当前的二进制日志名和偏移量值
show master status;

2.1.2. 从MySQL配置

从数据库服务器做相应设置，指定复制使用的用户，主数据库服务器的 IP、端
口以及开始执行复制的日志文件和位置等

change master to master_host='172.17.0.2', master_user='repl', master_password='123456', master_port=3306, master_log_file='mysql-bin.000002',master_log_pos=1064,master_connect_retry=60;

-- 在从服务器上，启动 slave 线程：
start slave;

-- 查看slave状态
show slave status\G;

-- 查看进程情况
show processlist \G;

如果slave状态及进程情况如下截图，则表明 slave 已经连接上 master，并开始接受并执行日志

• Slave_IO_Running：此进程负责从服务器（Slave）从主服务器（Master）上读取 BINLOG日志，并写入从服务器上的中继日志中。
• Slave_SQL_Running：此进程负责读取并且执行中继日志中的 BINLOG 日志。
  

2.3. 测试

2.3.1. 主库执行SQL

create database test default character set utf8 collate utf8_general_ci;
use test;
create table product(pid bigint,name varchar(20), price int);
insert into  product values(1,'moon',12);
insert into  product values(2,'mooncake',12);
insert into  product values(3,'orange',12);

2.3.2. 从库查询

select * from product;

3. MySQL主主配置

在主从配置的基础上，做如下操作

3.1. 配置

注意:

• 这里的主从是指 2. MySQL主从配置中的主从服务器
• 必须关闭级联复制 log-slave-updates=false

3.1.1. 在从MySQL配置

grant replication slave, replication client on *.* to 'repl'@'%' identified by '123456';
flush privileges;
--查看是否成功
select user,host from mysql.user;

--查看主服务器上当前的二进制日志名和偏移量值
show master status;

3.1.2. 在主MySQL配置

change master to master_host='172.17.0.3', master_user='repl', master_password='123456', master_port=3306, master_log_file='mysql-bin.000003',master_log_pos=667,master_connect_retry=60;

-- 启动 slave 线程：
start slave;

-- 查看slave状态
show slave status\G;

-- 查看进程情况
show processlist \G;

3.2. 数据写入测试

3.2.1. 从库执行SQL

insert into  product values(111,'moon',12);
insert into  product values(112,'mooncake',12);
insert into  product values(113,'orange',12);

3.2.2. 主库执行SQL

insert into  product values(114,'orange',12);
insert into  product values(115,'orange',12);

3.2.3. 主从库查询

select * from product where pid > 100;

3.3. 从或主服务器重启测试

• 将从或主服务器关闭service mysql stop
• 停一段时间如20秒后重启service mysql start
• 查看从或主服务器的slave状态show slave status \G; 可以看到，slave进行了正在进行重连，连接上主服务器后，Slave_IO_State: Waiting for master to send event



• 
  
• 重新执行3.2. 数据写入测试

insert into  product values(121,'moon',12);
insert into  product values(122,'mooncake',12);
insert into  product values(123,'orange',12);

insert into  product values(124,'orange',12);
insert into  product values(125,'orange',12);

select * from product where pid > 120;

4. 相关知识

4.1. GTID的局限性

gtid_mode = ONenforce-gtid-consistency = true

这两个参数是启用mysql5.6中的UUID同步模式，两个参数必须一起打开，否则报错
slave在做同步复制时，无须找到binlog日志和POS点，直接change master to master_auto_position=1即可，自动找点同步。

GTID的局限性： (鉴于这些局限性，慎用)

1. GTID同步复制是基于事务。所以Myisam表不支持，这可能导致多个GTID分配给同一个事务。
2. CREATE TABLE … SELECT语句不支持。因为该语句会被拆分成create table 和insert两个事务，并且这个两个事务被分配了同一个GTID，这会导致insert被备库忽略掉。
3. 不支持CREATE TEMPORARY TABLE、DROP TEMPORARY TABLE 临时表操作。

4.2. 查看MySQL变量配置

show variables like 'server_id'; 
show variables like '%binlog_%';
show variables like 'log_bin_t%';
show variables like 'slave_skip%';

4.3. slave_skip_errors

在复制过程中，由于各种原因，从服务器可能会遇到执行 BINLOG 中的 SQL 出错的情况（比如主键冲突），默认情况下，从服务器将会停止复制进程，不再进行同步，等待用户介入处理。这种问题如果不能及时发现，将会对应用或者备份产生影响。此参数的作用就是用来定
义复制过程中从服务器可以自动跳过的错误号，这样当复制过程中遇到定义中的错误号时，便可以自动跳过，直接执行后面的 SQL 语句，以此来最大限度地减少人工干预。

slave_skip_errors选项有四个可用值，分别为：off，all，ErorCode，ddl_exist_errors。
默认情况下该参数值是off，可以列出具体的error code，也可以选择all，mysql5.6及MySQL Cluster NDB 7.3以及后续版本增加了参数ddl_exist_errors，该参数包含一系列error code（1007,1008,1050,1051,1054,1060,1061,1068,1094,1146）
一些error code代表的错误如下：

• 1007：数据库已存在，创建数据库失败
• 1008：数据库不存在，删除数据库失败
• 1050：数据表已存在，创建数据表失败
• 1051：数据表不存在，删除数据表失败
• 1054：字段不存在，或程序文件跟数据库有冲突
• 1060：字段重复，导致无法插入
• 1061：重复键名
• 1068：定义了多个主键
• 1094：位置线程ID
• 1146：数据表缺失，请恢复数据库
• 1053：复制过程中主服务器宕机
• 1062：主键冲突 Duplicate entry ‘%s’ for key %d

my.cnf中的写法：

• slave_skip_errors=1062,1053
• slave_skip_errors=all
• slave_skip_errors=ddl_exist_errors

4.4. master_connect_retry

有时候是因为网络不稳定、网络闪断造成同步不正常,
如果Slave机器非常多一个一个登录服务器去stop slave、start slave既无聊又重复, 那么有没有办法解决呢?

早在MySQL5.1官方就推出相应的解决方案,参数master-connect-retry=seconds. 默认为60秒。

此参数官方给出的中文解释如下:

master-connect-retry 这个参数用来设置在和主服务器的连接丢失的时候，重试的时间间隔，

默认是 60 秒，即每 60 秒重试一次

replication-connection-configuration

4.5. 指定复制的数据库或者表

可以使用 replicate-do-db、replicate-do-table、replicate-ignore-db、replicate-ignore-table 或replicate-wild-do-table 来指定从主数据库复制到从数据库的数据库或者表。有些时候用户只需要将关键表备份到从服务器上，或者只需要将提供查询操作的表复制到从服务器上，这样就可以通过配置这几个参数来筛选进行同步的数据库和表。

使用示例

• --replicate-wild-do-table=foo%.bar% 只更新数据库名以foo开头、表名以bar开头的表。replicate-wild-do-table
• --replicate-do-table=db_name.tbl_name 将复制限制到给定表。若要指定多个表，请多次使用此选项，每个表一次。这对于跨数据库更新和默认数据库更新都有效

4.6. 主从服务器同步维护

在某些繁忙的 OLTP(在线事务处理)系统上，由于主服务器更新频繁，而从服务器由于各种原因（比如硬件性能较差）导致更新速度较慢，从而使得主从服务器之间的数据差距越来越大，最终对某些应用产生影响。

在负载较低的时候暂时阻塞主数据库的更新，强制主从数据库更新同步。操作步骤如下：

-- 在主服务器操作
-- 记录 SHOW 语句的输出的日志名和偏移量，这些是从服务器复制的目的坐标。
FLUSH TABLES WITH READ LOCK;

--在从服务器上操作
-- MASTER_POS_WAIT()函数的参数是前面步骤中得到的复制坐标值
-- 这个 SELECT 语句会阻塞直到从服务器达到指定的日志文件和偏移量后，返回 0，如果返回-1，则表示超时退出。查询返回 0 时，则从服务器与主服务器同步
select MASTER_POS_WAIT('mysql-bin.000039','974');

-- 在主服务器上，执行下面的语句允许主服务器重新开始处理更新
UNLOCK TABLES;

4.7. 如何导致某一个库的数据？

4.7.1. 从主库备份数据

flush tables with read lock;
--查看主服务器上当前的二进制日志名和偏移量值。这个操作的目的是为了在从数据库启动以后，从这个点开始进行数据的恢复
show master status;

--数据库导入操作，以下操作分别是备份全部数据、备份一个库的数据、备份一个表的数据
-- -F Flush logs file in server before starting dump.
-- -l Lock all tables for read.
mysqldump -uroot -p --all-database > all.sql
mysqldump -uroot -p test > test.sql
mysqldump -uroot -p test emp > emp.sql
mysqldump -uroot -p test emp dept > emp_dept.sql
mysqldump -uroot –p –l –F test >test.dmp

--主数据库的备份完毕后，主数据库可以恢复写操作，剩下的操作只需要在从服务器上执行：
unlock tables;

4.7.2. 在从库恢复数据

mysql -uroot -p test < test.dmp

4.8. read only

用来设置从服务器只能接受超级用户的更新操作，从而限制应用程序错误的对从服务器的更新操作

1. 设置read_only使mysql实例为只读。slave库设置read_only后可用当做查询库使用，但是这个只读不影响slave库应用binlog
2. read_only只限制普通用户修改数据，不会限制super权限的用户。如果要现在super用户，需要设置super_read_only
3. all privilege包含了super权限
4. 使用 read-only 启动的从数据库会拒绝普通用户的更新操作，以确保从数据库的安全性。

4.9. 如何解决多主复制时的自增长变量冲突问题

在大多数情况下，一般只使用单主复制（一台主服务器对一台或者多台从服务器）。
但是在某些情况下，可能会需要使用多主复制（多台主服务器对一台从服务器）。这个时候，如果主服务器的表采用自动增长变量，那么复制到从服务器的同一张表后很可能会引起主键冲突，因为系统参数 auto_increment_increment 和 auto_increment_offset 默认值为 1，这样多台主服务器的自增变量列迟早会发生冲突。
在单主复制时，可以采用默认设置，不会有主键冲 突 发 生 。 但 是 使 用 多 主 复 制 时 ， 就 需 要 定 制 auto_increment_increment 和
auto_increment_offset 的设置，保证多主之间复制到从数据库不会有重复冲突。比如，两个master 的情况可以按照以下设置。

• Master1 上：auto_increment_increment = 2，auto_increment_offset = 1；（1,3,5,7…序 列）
• Master2 上：auto_increment_increment = 2，auto_increment_offset = 2；（2,4,6,8…序 列）

测试SQL如下：

CREATE TABLE auto_id (id bigint(20) NOT NULL AUTO_INCREMENT,PRIMARY KEY (id));
--insert 分别在主、从服务器上执行
insert into auto_id values(null),(null),(null);
insert into auto_id values(null),(null),(null);
select * from auto_id;

SET @@auto_increment_increment=10;

4.10. 查看从服务器的复制进度

很多情况下，想知道从服务器复制的进度如何。知道了这个差距，可以判断是否需要手工来做主从的同步工作
这个值可以通过 SHOW PROCESSLIST 列表中的 Slave_SQL_Running 线程的 Time 值得到，它记录了从服务器当前执行的 SQL 时间戳与系统时间之间的差距，单位是秒。

由于 MySQL 复制的机制是执行主服务器传输过来的二进制日志，二进制日志中的每个语句通过设置时间戳来保证执行时间和顺序的正确性，所以每个语句执行之前都会首先设置时间戳，而通过查询这个进程的 Time 就可以知道最后设置的时间戳和当前时间的差距

下面通过例子测试一下这个时间的准确性

alter table auto_id add column createtime datetime;
stop slave IO_THREAD ;
--在主库插入数据
insert into auto_id (createtime) values(now());
--过一段时间，再启动IO_THREAD
SHOW PROCESSLIST;
start slave IO_THREAD ;
select * from auto_id ;
SHOW PROCESSLIST;

观察Slave_SQL_Running 线程的 Time 值的变化

4.11. 切换主从服务器

针对1主2从，如何进行主从服务器切换：
将其中的一个从数据库服务器如S1切换成主数据库服务器; 修改另一个从数据库（S2）的配置，使其指向新的主数据库（S1); 需要通知应用修改主数据库的 IP 地址，如果可能，将出现故障的主数据库（M）修复或者重置成新的从数据库。
操作步骤如下：

• 首先要确保所有的从数据库都已经执行了 relay log 中的全部更新，在每个从服务器上，执行 STOP SLAVE IO_THREAD，然后检查 SHOW PROCESSLIST 的输出，直到看到状态是 Has read all relay log，表示更新都执行完毕
• 如果主库可正常访问，则执行如下操作

• 切换前将原主库的表上锁，防止切换数据库期间出现数据写入 flush tables with read lock;
• change master到新的主库（待新的主库配置完成后执行）

• 在从数据库 S1 上，执行 STOP SLAVE 停止从服务，执行reset slave all，使其断开与老主库的连接，然后 RESET MASTER 重置成主数据库
• 在 S2 上，执行 STOP SLAVE 停止从服务，然后执行 CHANGE MASTER TO MASTER_HOST= 'S1'重新设置主数据库，然后再执行 START SLAVE 启动复制。
• 通知所有的客户端将应用指向 S1，这样客户端发送的所有的更新语法写入到 S1 的二进制日志。
• 最后，如果 M 服务器可以修复，则可以按照 S2 的方法配置成 S1 的从服务器

注意: 上面的测试有如下2个假设：

• 假设S1 是打开 log-bin 选项的，这样重置成主数据库后可以将二进制日志传输到其他从服务器。
• 假设S1 上没有打开 log-slave-updates 参数，否则重置成主数据库后，可能会将已经执行过的二进制日志重复传输给 S2，导致 S2 的同步错误。

4.12. reset slave，reset slave all，reset master都干了些啥？

• reset slave

• 清理掉master.info
• 清理relay-log.info
• 删除所有的relay log文件，重启用一个新的relay log文件
• 不清理内存里的同步复制配置信息。清除slave 复制时的master binlog的位置，重置复制延迟(CHANGE MASTER TO 的 MASTER_DELAY参数指定的)为0，不会改变复制连接使用的参数，例如master host, master port, master user, or master password
• 不重置 gtid_executed or gtid_purged 参数值

• reset slave all

• 清理掉master.info
• 清理relay-log.info
• 删除所有的relay log文件，重启用一个新的relay log文件
• 立即清理内存里的同步复制配置信息。这一点很有用：提升从库为主库，特别是在集群迁移中，新集群的新主库同步了旧集群的旧主库后，需要断开,则执行
  stop slave;
  reset slave all;
  show slave status\G;
  此时真正实现了清除slave同步复制关系！
  mysql主从复制中，需要将从库提升为主库，需要取消其从库角色，这可通过执行RESET SLAVE ALL清除从库的同步复制信息、包括连接信息和二进制文件名、位置。从库上执行这个命令后，使用show slave status将不会有输出。
• 不重置 gtid_executed or gtid_purged 参数值

• reset master

• 删除binlog索引文件中列出的所有binlog文件
• 清空binlog索引文件
• 创建一个新的binlog文件
• 清空系统变量gtid_purged和gtid_executed， 在MySQL 5.7.5 及后续版本中, RESET MASTER还会会清空 mysql.gtid_executed数据表。

用途：删除所有的binglog日志文件，并将日志索引文件清空，重新开始所有新的日志文件。用于第一次进行搭建主从库时，进行主库binlog初始化工作；

注意：但是如果当前是主数据库，且主从数据库正常的时候，千万不能用这种方式删除。

4.13. 如何为集群添加一个新实例作为从库

当启动新的实例后按如下顺序执行：

stop slave;
reset slave all;
reset master;
change master (根据实际情况而定)
start slave;
show slave status\G;

4.14. 复制原理

MySQL主从复制涉及到三个线程

• 一个运行在主节点（Binary log dump thread），
• 其余两个(Replication I/O thread, Replication SQL thread)运行在从节点，如下图所示
• 主节点 binary log dump 线程
  当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的 bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。
• 从节点SQL线程

• I/O thread 读取主服务器的Binlog Dump线程发送的更新，并将它们复制并写到本地的relay log中。
• SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

对于每一个主从连接，都需要三个进程来完成。

• 当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，
• 每个从节点都有自己的I/O进程，SQL进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时I/O进程可以很快从主节点获取更新，尽管SQL进程还没有执行。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后，就可以完成数据的同步。

5. 遇到的问题

5.1. Warning: World-writable config file ‘/etc/my.cnf’ is ignored

因为配置文件在windows下，所以采用如下方式：

• 使用git bash工具，进行到D:\docker\mysql\master\conf目录，执行：chmod 644 my.cnf
• 启动容器，命令行进入，执行：chmod 644 /etc/mysql/my.cnf

5.2. 从MySQL连接不上主MySQL

出现这个问题，是由于change master中的主MySQL的相关信息配置错误，在容器中主要是IP配置错误
master_host='172.17.0.2'中的IP地址需要配置为容器的IP地址，

可以使用如下命令查看容器的IP地址

docker inspect mysql-master
docker inspect mysql-master --format="{{json .NetworkSettings.Networks}}"

5.3. binlog-row-p_w_picpath 参数不存在

看网上很多资料，都讲要配置这个参数，但这个参数在mysql官网文档找不到。
binlog-row-p_w_picpath=minimal
这个参数允许应用程序只能对行的镜像数据进行复制，而不在关心行是否已经进行了DML操作，从而提高了主从机器的复制吞吐量，减少了二进制日志所占用的磁盘空间、网络资源和内存占用

5.4. Slave failed to initialize relay log info structure from the repository 的报错问题

报错信息：Slave failed to initialize relay log info structure from the repository 从服务器无法从储存库初始化中继日志信息结构；
报错原因:从库里面已经存在之前的中继日志（relay log）

解决方法：
在从库中操作：

mysql>stop slave;
mysql>reset slave;

清除master信息和relay log的信息，删除所有的relay log文件，并创建一个全新的中继日志

5.5. 从服务器复制出错的处理

在某些情况下，会出现从服务器更新失败

• 如果是从服务器的表与主服务上的表结构不同，则将从服务器的表的结构修改为与主服务器一致，然后重新启动slave start slave
• 如果不是表结构不同导致的更新失败，则需要确认手动更新是否安全，然后忽视来自主服 务 器 的 更 新 失 败 的 语 句

• 在备库上设置 set global sql_slave_skip_counter =N 会跳过当前时间来自于master的之后N个事件,这对于恢复由某条SQL语句引起的从库复制有效.
• 其中 n 的取值为 1 或者 2。如果来自主服务器的更新语句不使用 AUTO_INCREMENT 或 LAST_INSERT_ID()，n 值应为 1，否则，值应为 2。原因是使用AUTO_INCREMENT 或 LAST_INSERT_ID()的语句需要从二进制日志中取两个事件。

5.6. log event entry exceeded max_allowed_packet 的处理

如果应用中使用大的 BLOG 列或者长字符串，那么在从服务器上恢复的时候，可能会出现“log event entry exceeded max_allowed_packet”错误，这是因为含有大文本的记录无法通过网络进行传输导致。解决的办法就是在主从服务器上增加 max_allowed_packet 参数的大小，这个参数的默认值为 4MB，可以按照实际需要进行修改

show variables like 'max_allowed_packet';

SET @@global.max_allowed_packet=16777216;

6. 参考

参考文档

mysql docreplication-implementation-details 《深入浅出MySQL.pdf》

my.cnf配置

[mysqld]
port=3306
max_connections=10
max_connect_errors=10
character-set-server=utf8mb4
default-storage-engine=INNODB
lower_case_table_names=1
explicit_defaults_for_timestamp=on


# mysql 复制功能配置
## 同一局域网内注意要唯一
server-id=2

## 需要写入日志的数据库
binlog-do-db=test

## 不需要复制的数据库名
replicate-ignore-db=mysql
replicate-ignore-db=sys
replicate-ignore-db=information_schema
replicate-ignore-db=performance_schema

## 偶数ID
auto_increment_offset=2
auto_increment_increment=2   


## 开启级联复制：为了让从库从主库复制数据时可以写入到binlog日志【从库要作为其他从库的主库，必须添加该参数】
## 从库开启log-bin参数，如果直接往从库写数据，是可以记录log-bin日志的，
## 但是从库通过I0线程读取主库二进制日志文件，然后通过SQL线程写入的数据，是不会记录binlog日志的
log-slave-updates=false

## 开启二进制日志功能，MASTER主服务器必须打开此项
log-bin = mysql-bin 
## 主从复制的格式（mixed,statement,row，默认格式是statement）
binlog-format=row
## 为每个session 分配的内存，在事务过程中用来存储二进制日志的缓存，用于提高记录bin-log的效率，默认为32K
binlog_cache_size=1M
## 单个binlog文件最大值，如果超过该值，则产生新的binlog文件，后缀名+1，并记录到.index文件。
max_binlog_size=1024M
## write 和 fsync 的时机
### 0的时候，表示每次提交事务都只 write，不 fsync；
### 1 的时候，表示每次提交事务都会执行 fsync；
### >1时表示每次提交事务都 write，但累积 N 个事务后才 fsync。
sync_binlog=1
## 允许应用程序只能对行的镜像数据进行复制，而不在关心行是否已经进行了DML操作。
## 这提高了主从机器的复制吞吐量，减少了二进制日志所占用的磁盘空间、网络资源和内存占用
## binlog-row-p_w_picpath=minimal
## 默认是0，不开启，最大并发数为1024个线程。主从复制启用4个sql线程，提高从服务器吞吐量，减少延迟,
## 使用并发的 SQL 线程对不同数据库并行应用事件，如果只同步一个库的，指定为0，否则会阻塞
slave-parallel-workers=0
## 开启GTID模式
gtid-mode=on
## 在启用基于GTID的复制之前，必须将此选项设置为true，取值可以为true,false,warn
## true 不允许事务违反GTID一致性, 允许事务违反GTID一致性，但在这种情况下会生成警告
enforce-gtid-consistency=on
## 可用于实现在崩溃时保证二进制及从服务器安全的功能
## 复制信息表用于在从库在复制主库的数据期间，用于保存从主库转发到从库的二进制日志事件、记录有关中继日志当前状态和位置的信息
master-info-repository=TABLE
relay-log-info-repository=TABLE
## 每N个事件后，slave就会更新mysql.slave_master_info表
sync-master-info=1
## 启用复制有关的所有校验功能
master-verify-checksum=1
slave-sql-verify-checksum=1
## 写入binlog进行校验，有两个值[crc32|none],默认为crc32
binlog-checksum=CRC32
## 可用于在二进制日志记录事件相关的信息，可降低故障排除的复杂度
binlog-rows-query-log_events=1
## 控制binlog日志文件保留时间，超过保留时间的binlog日志会被自动删除
expire_logs_days=30

## slave增加的配置
## 如果需要同步函数或者存储过程
log_bin_trust_function_creators=on
## 定义复制过程中从服务器可以自动跳过的错误号，当复制过程中遇到定义的错误号，就可以自动跳过，直接执行后面的SQL语句
slave_skip_errors=ddl_exist_errors

[mysql]
default-character-set=utf8mb4

[client]
port=3306
default-character-set=utf8mb4