docker 运行mysql5.7
本文主要分享在ubuntu20.04下通过docker安装mysql 5.7的相关实操，通常介于多方面因素我们不会将mysql运行在docker下，但对数据不是很敏感下，又想快速部署相关服务或者简单的开发测试，我们也是可以通过docker运行mysql的。
环境：
- ubuntu 20.04
- docker 20.10
- mysql 5.7
- navicat
1.镜像及容器运行
下载镜像
docker pull mysql:5.7
# 查看镜像
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
mysql 5.7 0018a8d83892 9 days ago 455MB
宿主机挂载目录准备
mkdir -p /data/mysql/{data,logs}
mkdir -p /data/mysql/conf/{conf.d,mysql.conf.d}
创建docker启动脚本
#! /bin/bash
docker run -d --name mysql5.7 \
-p 3306:3306 \
-e MYSQL_ROOT_PASSWORD=123456 \ # 容器的环境变量(root账号初始化密码)
--privileged=true \ # 容器拥有root权限
-v /data/mysql/data:/var/lib/mysql \ # 容器MySQL数据目录映射(宿主机:容器)
-v /data/mysql/conf:/etc/mysql/ \ # 容器MySQL配置目录映射(宿主机:容器)
-v /data/mysql/logs:/var/log/mysql \ # 容器MySQL日志目录映射(宿主机:容器)
mysql:5.7
启动容器
pwd
# /data/mysql
ls
# conf data docker_run.sh logs
sh docker_run.sh
# 查看容器
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9522dc4b6184 mysql:5.7 "docker-entrypoint.s…" 34 minutes ago Up 34 minutes 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060/tcp mysql5.7
docker top mysql5.7
UID PID PPID C STIME TTY TIME CMD
systemd+ 72615 72592 0 10:33 ? 00:00:01 mysqld
root 72893 72592 0 10:34 pts/0 00:00:00 bash
root 72900 72893 0 10:34 pts/0 00:00:00 mysql -u root -p
到这里，mysql容器是正常运行起来了的。
2.mysql容器的一些配置
进入容器
docker exec -it mysql:5.7 bash
# 进入mysql交互，输入docker run 的root密码
mysql -u root -p
通常我们在分配权限时都会设置root用户和普通用户，给普通用户设置相关的数据库权限，限制访问，保证数据库库层面的数据隔离。
接下来分享数据库权限配置：
# 创建用户且开启远程登录: CREATE USER '你的账号'@'%' IDENTIFIED BY '你的密码';
create user 'test'@'%' identified by 'changeme';
# 创建数据库
create database `test` character set 'utf8mb4';
# 设置账号权限
grant all privileges on test.* to 'test'@'%';
我们通过navicat查看是否设置成功，查看mysql.db表：
可以看到已经限制了相关用户的库权限。
3.mysql的常用配置-mysql.cnf
# +--------------+
# | 客户端基本设置 |
# +--------------+
[client]
# 默认连接端口
port = 3306
# 用于本地连接的socket套接字
socket = /usr/local/mysql/data/mysql.sock
# 编码
default-character-set = utf8mb4
# +--------------+
# | 服务端基本设置 |
# +--------------+
[mysqld]
# MySQL监听端口
port = 3306
# 为MySQL客户端程序和服务器之间的本地通讯指定一个套接字文件
socket = /usr/local/mysql/data/mysql.sock
# pid文件所在目录
pid-file = /usr/local/mysql/data/mysql.pid
# 使用该目录作为根目录（安装目录）
basedir = /usr/local/mysql
# 数据文件存放的目录
datadir = /usr/local/mysql/database
# MySQL存放临时文件的目录
tmpdir = /usr/local/mysql/data/tmp
# 服务端默认编码（数据库级别）
character_set_server = utf8mb4
# 服务端默认的比对规则，排序规则
collation_server = utf8mb4_bin
# MySQL启动用户。如果是root用户就配置root，mysql用户就配置mysql
user = root
# 错误日志配置文件(configure file)
log-error=/usr/local/mysql/data/error.log
# 设置允许 load data导入、导出的位置
secure-file-priv = ''
# 开启了binlog后，必须设置这个值为1.主要是考虑binlog安全
# 此变量适用于启用二进制日志记录的情况。它控制是否可以信任存储函数创建者，
# 而不是创建将导致要写入二进制日志的不安全事件。如果设置为0（默认值），
# 则不允许用户创建或更改存储函数，除非用户具有
# 除创建例程或更改例程特权之外的特权
log_bin_trust_function_creators = 1
# 性能优化的引擎，默认关闭
performance_schema = 0
# 开启全文索引
ft_min_word_len = 1
# 自动修复MySQL的myisam表
myisam_recover
# 明确时间戳默认null方式
explicit_defaults_for_timestamp
# 计划任务（事件调度器）
event_scheduler
# 跳过外部锁定;External-locking用于多进程条件下为MyISAM数据表进行锁定
skip-external-locking
# 跳过客户端域名解析；当新的客户连接mysqld时，
# mysqld创建一个新的线程来处理请求。
# 该线程先检查是否主机名在主机名缓存中。如果不在，线程试图解析主机名。
#
# 使用这一选项以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，
# 则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求!
skip-name-resolve
# MySQL绑定IP
# 1.这个bind-address强烈推荐不配置
#
# 2.如果要配置bind-address的话，这个localhost不能修改，
# 否则在初始化数据库(执行/opt/cloudera/cm/schema/scm_prepare_database.sh
# mysql cm cm password)时便会报错
# 如果配置了localhost的话，那么在CDH的安装页面中，配置连接数据库的主机名称必须为localhost
#
# 3.强烈不推荐写bind-address=xxx，
# 那么后面的CDH安装对应的组件时要填写的“数据库主机名称”默认使用主机名。
#
# 4.如果/etc/my.cnf中配置了bind-address=localhost 的话，
# 那么在CDH的安装页面中，配置连接数据库的主机名称必须为localhost。
# 缺点：但是在安装hue时，“数据库主机名称”并无法使用localhost或任何主机名，所以造成无法安装hue
#
# 5.不配置 bind-address=localhost 的话，则使用主机名(NDOE1)作为此处的数据库主机名称
bind-address=localhost
# 为了安全起见，复制环境的数据库还是设置--skip-slave-start参数，防止复制随着mysql启动而自动启动
skip-slave-start
# 在中止读取之前等待来自主/从连接的更多数据的秒数。 MySQL主从复制的时候，
# 当Master和Slave之间的网络中断，但是Master和Slave无法察觉的情况下（比如防火墙或者路由问题）。
# Slave会等待slave_net_timeout设置的秒数后，
# 才能认为网络出现故障，然后才会重连并且追赶这段时间主库的数据。
#
# 1.用这三个参数来判断主从是否延迟是不准确的Slave_IO_Running,Slave_SQL_Running,
# Seconds_Behind_Master.还是用pt-heartbeat吧。
# 2.slave_net_timeout不要用默认值，设置一个你能接受的延时时间。
slave_net_timeout = 30
# 设定是否支持命令load data local infile。如果指定local关键词，则表明支持从客户主机读文件
local-infile = 0
# 指定MySQL可能的连接数量。
# 当MySQL主线程在很短的时间内得到非常多的连接请求，该参数就起作用，
# 之后主线程花些时间（尽管很短）检查连接并且启动一个新线程。
#
# back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。
back_log = 1024
# sql_mode是一组语法校验规则
# 常用的参数有:
# ONLY_FULL_GROUP_BY
# (对于GROUP BY聚合操作，如果在SELECT中的列，没有在GROUP BY中出现，
# 那么这# 个SQL是不合法的，因为列不在GROUP BY从句中)
#
# NO_AUTO_VALUE_ON_ZERO
# (该值影响自增长列的插入。默认设置下，插入0或NULL代表生成下一个自增长值。
# 如果用户希望插入的值为0，而该列又是自增长的，那么这个选项就有用了。)
#
# STRICT_TRANS_TABLES
# (如果一个值不能插入到一个事务中，则中断当前的操作，对非事务表不做限制)
#
# NO_ZERO_IN_DATE (不允许日期和月份为零)
#
# NO_ZERO_DATE
# (mysql数据库不允许插入零日期，插入零日期会抛出错误而不是警告)
#
# ERROR_FOR_DIVISION_BY_ZERO
# (在insert或update过程中，如果数据被零除，则产生错误而非警告。
# 如果未给出该模式，那么数据被零除时Mysql返回NULL)
#
# NO_AUTO_CREATE_USER
# (禁止GRANT创建密码为空的用户 MySQL8.0已取消配置将无法启动)
#
# NO_ENGINE_SUBSTITUTION
# (如果需要的存储引擎被禁用或未编译，那么抛出错误。
# 不设置此值时，用默认的存储引擎替代，并抛出一个异常)
#
# PIPES_AS_CONCAT
# (将"||"视为字符串的连接操作符而非或运算符，
# 这和Oracle数据库是一样是，也和字符串的拼接函数Concat想类似)
#
# ANSI_QUOTES (不能用双引号来引用字符串，因为它被解释为识别符)
sql_mode = PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
# 索引块的缓冲区大小，对MyISAM表性能影响最大的一个参数.决定索引处理的速度，
# 尤其是索引读的速度。默认值是16M，通过检查状态值Key_read_requests
#
# 和Key_reads，可以知道key_buffer_size设置是否合理
key_buffer_size = 32M
# 一个查询语句包的最大尺寸。消息缓冲区被初始化为net_buffer_length字节，
# 但是可在需要时增加到max_allowed_packet个字节。
#
# 该值太小则会在处理大包时产生错误。如果使用大的BLOB列，必须增加该值。
#
# 这个值来限制server接受的数据包大小。
# 有时候大的插入和更新会受max_allowed_packet 参数限制，导致写入或者更新失败。
max_allowed_packet = 512M
# 线程缓存；主要用来存放每一个线程自身的标识信息，
# 如线程id，线程运行时基本信息等等，
# 我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。
thread_stack = 256K
# 是MySQL执行排序使用的缓冲大小。
# 如果想要增加ORDER BY的速度，首先看是否可以让MySQL使用索引而不是额外的排序阶段。
# 如果不能，可以尝试增加sort_buffer_size变量的大小。
sort_buffer_size = 16M
# 是MySQL读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，
# MySQL会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。
#
# 如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，
# 可以通过增加该变量值以及内存缓冲区大小提高其性能。
read_buffer_size = 16M
# 应用程序经常会出现一些两表（或多表）Join的操作需求，
# MySQL在完成某些 Join 需求的时候（all/index join），为了减少参与Join的“被驱动表”
# 的读取次数以提高性能，需要使用到 Join Buffer 来协助完成 Join操作。
# 当 Join Buffer 太小，MySQL 不会将该 Buffer 存入磁盘文件，
# 而是先将Join Buffer中的结果集与需要 Join 的表进行 Join 操作，
# 然后清空 Join Buffer 中的数据，继续将剩余的结果集写入此 Buffer 中，
# 如此往复。这势必会造成被驱动表需要被多次读取，成倍增加 IO 访问，降低效率。
join_buffer_size = 16M
# 是MySQL的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，
# 将分配一个随机读缓存区。进行排序查询时，MySQL会首先扫描一遍该缓冲，以避免磁盘搜索，
# 提高查询速度，如果需要排序大量数据，可适当调高该值。
# 但MySQL会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
read_rnd_buffer_size = 32M
# 通信缓冲区在查询期间被重置到该大小。通常不要改变该参数值，
# 但是如果内存不足，可以将它设置为查询期望的大小。
# （即，客户发出的SQL语句期望的长度。如果语句超过这个长度，
# 缓冲区自动地被扩大，直到max_allowed_packet个字节。）
net_buffer_length = 16K
# 当对MyISAM表执行repair table或创建索引时，用以缓存排序索，
# 设置太小时可能会遇到” myisam_sort_buffer_size is too small”
myisam_sort_buffer_size = 128M
# 默认8M，当对MyISAM非空表执行insert … select/ insert … values(…),(…)或者load data infile时，
# 使用树状cache缓存数据，每个thread分配一个；
# 注：当对MyISAM表load 大文件时，
# 调大bulk_insert_buffer_size/myisam_sort_buffer_size/key_buffer_size会极大提升速度
bulk_insert_buffer_size = 32M
# thread_cahe_size线程池，线程缓存。用来缓存空闲的线程，
# 以至于不被销毁，如果线程缓存在的空闲线程，需要重新建立新连接，
# 则会优先调用线程池中的缓存，
# 很快就能响应连接请求。每建立一个连接，都需要一个线程与之匹配。
thread_cache_size = 384
# 工作原理： 一个SELECT查询在DB中工作后，DB会把该语句缓存下来，
# 当同样的一个SQL再次来到DB里调用时，
# DB在该表没发生变化的情况下把结果从缓存中返回给Client。
# 在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。
# 而且在高并发，写入量大的系统，建系把该功能禁掉。
query_cache_size = 0
# 决定是否缓存查询结果。这个变量有三个取值：0,1,2，分别代表了off、on、demand。
query_cache_type = 0
# 它规定了内部内存临时表的最大值，每个线程都要分配。
# （实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。）
# 如果内存临时表超出了限制，MySQL就会自动地把它转化为基于磁盘的MyISAM表，存储在指定的tmpdir目录下
tmp_table_size = 1024M
# 独立的内存表所允许的最大容量.
# 此选项为了防止意外创建一个超大的内存表导致永尽所有的内存资源.
max_heap_table_size = 512M
# mysql打开最大文件数
open_files_limit = 10240
# MySQL无论如何都会保留一个用于管理员（SUPER）登陆的连接，
# 用于管理员连接数据库进行维护操作，即使当前连接数已经达到了max_connections。
#
# 因此MySQL的实际最大可连接数为max_connections+1；
# 这个参数实际起作用的最大值（实际最大可连接数）为16384，
# 即该参数最大值不能超过16384，即使超过也以16384为准；
#
# 增加max_connections参数的值，不会占用太多系统资源。
# 系统资源（CPU、内存）的占用主要取决于查询的密度、效率等；
#
# 该参数设置过小的最明显特征是出现”Too many connections”错误；
max_connections = 2000
# 用来限制用户资源的，0不限制；对整个服务器的用户限制
max-user-connections = 0
# max_connect_errors是一个MySQL中与安全有关的计数器值，
# 它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。
# max_connect_errors的值与性能并无太大关系。
# 当此值设置为10时，意味着如果某一客户端尝试连接此MySQL服务器，
# 但是失败（如密码错误等等）10次，则MySQL会无条件强制阻止此客户端连接。
max_connect_errors = 100000
# 表描述符缓存大小，可减少文件打开/关闭次数；
table_open_cache = 5120
# 指的是mysql在关闭一个交互的连接之前所要等待的秒数
# (交互连接如mysql gui tool中的连接超时时间)
# (通过mysql客户端连接数据库是交互式连接，通过jdbc连接数据库是非交互式连接)
interactive_timeout = 86400
# 指的是MySQL在关闭一个非交互的连接超时要等待的秒数
# (通过mysql客户端连接数据库是交互式连接，通过jdbc连接数据库是非交互式连接)
wait_timeout = 86400
# 二进制日志缓冲大小
# 我们知道InnoDB存储引擎是支持事务的，实现事务需要依赖于日志技术，为了性能，
# 日志编码采用二进制格式。那么，我们如何记日志呢？有日志的时候，就直接写磁盘？
# 可是磁盘的效率是很低的，如果你用过Nginx，，一般Nginx输出access log都是要缓冲输出的。
# 因此，记录二进制日志的时候，我们是否也需要考虑Cache呢？
# 答案是肯定的，但是Cache不是直接持久化，于是面临安全性的问题——因为系统宕机时，
# Cache中可能有残余的数据没来得及写入磁盘。因此，Cache要权衡，要恰到好处：
# 既减少磁盘I/O，满足性能要求；又保证Cache无残留，及时持久化，满足安全要求。
binlog_cache_size = 16M
# 开启慢查询
slow_query_log = true
# 慢查询地址
slow_query_log_file = /usr/local/mysql/data/slow_query_log.log
# 超过的时间为1s；MySQL能够记录执行时间超过参数 long_query_time 设置值的SQL语句，默认是不记录的。
long_query_time = 1
# 开启记录管理型慢SQL
log-slow-admin-statements
# 记录管理语句和没有使用index的查询记录
log-queries-not-using-indexes
# +--------------+
# | 主从复制配置 |
# +--------------+ start.
# 在复制方面的改进就是引进了新的复制技术：基于行的复制。
# 简言之，这种新技术就是关注表中发生变化的记录，而非以前的照抄 binlog 模式。
#
# 从 MySQL 5.1.12 开始，可以用以下三种模式来实现：
# -基于SQL语句的复制(statement-based replication, SBR)，
# -基于行的复制(row-based replication, RBR)，
# -混合模式复制(mixed-based replication, MBR)。
#
# 相应地，binlog的格式也有三种：STATEMENT，ROW，MIXED。
# MBR 模式中，SBR 模式是默认的。
binlog_format = ROW
# 为每个session 最大可分配的内存，在事务过程中用来存储二进制日志的缓存。
# max_binlog_cache_size = 102400
# 开启二进制日志功能，binlog数据位置
log-bin = /usr/local/mysql/data/binlog/mysql-bin
# binlog文件的索引文件，这个文件管理了所有的binlog文件的目录
log-bin-index = /usr/local/mysql/data/binlog/mysql-bin.index
# relay-log日志记录的是从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，
# 然后SQL线程会读取relay-log日志的内容并应用到从服务器
relay-log = /usr/local/mysql/data/relay/mysql-relay-bin
# binlog传到备机被写道relaylog里，备机的slave sql线程从relaylog里读取然后应用到本地。
relay-log-index = /usr/local/mysql/data/relay/mysql-relay-bin.index
# ==================================================================
#**************
# 主服务器配置
#**************
# 服务端ID，用来高可用时做区分
server-id = 1
# 指定 database 不被记录binlog
# 不同步哪些数据库，除此之外，其他不同步
# ("binlog-ignore-db"和"binlog-do-db"为互斥关系，一般只选择其一设置)
binlog-ignore-db = mysql
binlog-ignore-db = sys
binlog-ignore-db = binlog
binlog-ignore-db = relay
binlog-ignore-db = tmp
binlog-ignore-db = test
binlog-ignore-db = information_schema
binlog-ignore-db = performance_schema
# 指定 database 记录binlog
# 同步哪些数据库
# ("binlog-ignore-db"和"binlog-do-db"为互斥关系，一般只选择其一设置)
binlog-do-db = db_1
binlog-do-db = db_2
#**************
# 从服务器配置
#**************
# 服务端ID，用来高可用时做区分
server-id = 2
# 不要需要同步的database
replicate-ignore-db = mysql
replicate-ignore-db = sys
replicate-ignore-db = relay
replicate-ignore-db = tmp
replicate-ignore-db = test
replicate-ignore-db = information_schema
replicate-ignore-db = performance_schema
# 需要同步的database
# 只同步哪些数据库，除此之外，其他不同步
replicate-do-db = db_1
replicate-do-db = db_2
# ==================================================================
# 将从服务器从主服务器收到的更新记入到从服务器自己的二进制日志文件中。
log_slave_updates = 1
# 二进制日志自动删除的天数。默认值为0,表示“没有自动删除”。启动时和二进制日志循环时可能删除。
expire-logs-days = 15
# 如果二进制日志写入的内容超出给定值，日志就会发生滚动。
# 你不能将该变量设置为大于1GB或小于4096字节。 默认值是1GB。
max_binlog_size = 128M
# 同步所有跨数据库的更新，比如replicate-do-db或者replicate-ignore-db不会同步类似
# replicate-wild-ignore-table = mysql.%
# 设定需要同步的Table
replicate-wild-do-table = db_name.%
# 复制时跳过一些错误;不要胡乱使用这些跳过错误的参数，
# 除非你非常确定你在做什么。当你使用这些参数时候，MYSQL会忽略那些错误，
# 这样会导致你的主从服务器数据不一致。
slave-skip-errors = 1062,1053,1146
# 表示id的起始值从1开始增长(但不表示第一个id就是1)
auto_increment_offset = 1
# 表示id的增长偏移量为2，就是下一个id比上一个id大2
auto_increment_increment = 2
# 将中继日志的信息写入表:mysql.slave_realy_log_info
relay_log_info_repository = TABLE
# 将master的连接信息写入表：mysql.salve_master_info
master_info_repository = TABLE
# 中继日志自我修复；当slave从库宕机后，假如relay-log损坏了，
# 导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，
# 并且重新从master上获取日志，这样就保证了relay-log的完整性
relay_log_recovery = on
# +--------------+
# | 主从复制配置 |
# +--------------+ end.
# +--------------+
# | innodb设置 |
# +--------------+
# InnoDB 用来高速缓冲数据和索引内存缓冲大小。 更大的设置可以使访问数据时减少磁盘 I/O。
innodb_buffer_pool_size = 128M
# 单独指定数据文件的路径与大小
innodb_data_file_path = ibdata1:10M:autoextend
# 每次commit 日志缓存中的数据刷到磁盘中。通常设置为 1，
# 意味着在事务提交前日志已被写入磁盘,事务可以运行更长以及服务崩溃后的修复能力。
# 如果你愿意减弱这个安全，或你运行的是比较小的事务处理，
# 可以将它设置为 0 ，以减少写日志文件的磁盘 I/O。这个选项默认设置为 0。
innodb_flush_log_at_trx_commit = 2
# sync_binlog：这个参数是对于MySQL系统来说是至关重要的，
# 他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。
# sync_binlog=0
# (当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，
# 而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘)
#
# sync_binlog=n
# (当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。)
sync_binlog=0
# 读线程个数，默认是4个(可根据CPU核心数配置)
innodb_read_io_threads = 8
# 写线程个数，默认是4个(可根据CPU核心数配置)
innodb_write_io_threads = 8
# 限制Innodb能打开的表的数量
innodb_open_files = 1000
# 开始碎片回收线程。这个应该能让碎片回收得更及时而且不影响其他线程的操作
innodb_purge_threads = 1
# InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 1M 至 8M。
# 大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交(commit)。
# 因此，如果有大的事务处理，设置大的日志缓冲可以减少磁盘I/O。
innodb_log_buffer_size = 8M
# 日志组中的每个日志文件的大小(单位 MB)。如果 n 是日志组中日志文件的数目，
# 那么理想的数值为 1M 至下面设置的缓冲池(buffer pool)大小的 1/n。较大的值，
# 可以减少刷新缓冲池的次数，从而减少磁盘 I/O。
# 但是大的日志文件意味着在崩溃时需要更长的时间来恢复数据。
innodb_log_file_size = 128M
# 指定有三个日志组
innodb_log_files_in_group = 3
# 在回滚(rooled back)之前，InnoDB 事务将等待超时的时间(单位 秒)
innodb_lock_wait_timeout = 120
# innodb_max_dirty_pages_pct作用：控制Innodb的脏页在缓冲中在那个百分比之下，
# 值在范围1-100,默认为90.这个参数的另一个用处：
# 当Innodb的内存分配过大，致使swap占用严重时，可以适当的减小调整这个值，
# 使达到swap空间释放出来。建义：这个值最大在90%，最小在15%。
# 太大，缓存中每次更新需要致换数据页太多，太小，放的数据页太小，更新操作太慢。
innodb_max_dirty_pages_pct = 75
# innodb_buffer_pool_size 一致 可以开启多个内存缓冲池，
# 把需要缓冲的数据hash到不同的缓冲池中，这样可以并行的内存读写。
innodb_buffer_pool_instances = 4
# innodb刷新脏页的能力
# 这个参数据控制Innodb checkpoint时的IO能力
innodb_io_capacity = 500
# 作用：使每个Innodb的表，有自已独立的表空间。如删除文件后可以回收那部分空间。
# 分配原则：只有使用不使用。但ＤＢ还需要有一个公共的表空间。
innodb_file_per_table = 1
# 当更新/插入的非聚集索引的数据所对应的页不在内存中时（对非聚集索引的更新操作通常会带来随机IO），
# 会将其放到一个insert buffer中，当随后页面被读到内存中时，会将这些变化的记录merge到页中。
# 当服务器比较空闲时，后台线程也会做merge操作
innodb_change_buffering = inserts
# 该值影响每秒刷新脏页的操作，开启此配置后，
# 刷新脏页会通过判断产生重做日志的速度来判断最合适的刷新脏页的数量；
innodb_adaptive_flushing = 1
# 数据库事务隔离级别 ，读取提交内容
transaction-isolation = READ-COMMITTED
# 控制着innodb数据文件及redo log的打开、刷写模式
# InnoDB使用O_DIRECT模式打开数据文件，用fsync()函数去更新日志和数据文件。
innodb_flush_method = fsync
# 默认设置值为1.设置为0：表示Innodb使用自带的内存分配程序；
# 设置为1：表示InnoDB使用操作系统的内存分配程序。
innodb_use_sys_malloc = 1
# +--------------+
# | 逻辑备份设置 |
# +--------------+
[mysqldump]
# 它强制 mysqldump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中
quick
# 限制server接受的数据包大小;指代mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
max_allowed_packet = 512M
# TCP/IP和套接字通信缓冲区大小,创建长度达net_buffer_length的行
net_buffer_length = 16384
[mysql]
# auto-rehash是自动补全的意思
auto-rehash
# isamchk数据检测恢复工具
[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
# 使用myisamchk实用程序来获得有关你的数据库桌表的信息、检查和修复他们或优化他们
# myisamchk默认只用3M的内存来修复，如果要修复大表的话，
# 显然速度会巨慢，我们可以通过为myisamchk设置更多的内存，来使其运行的更快，
[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
# mysqlhotcopy使用lock tables、flush tables和cp或scp来快速备份数据库.
# 它是备份数据库或单个表最快的途径,完全属于物理备份,
# 但只能用于备份MyISAM存储引擎和运行在数据库目录所在的机器上.
# 与mysqldump备份不同,mysqldump属于逻辑备份,备份时是执行的sql语句.
# 使用mysqlhotcopy命令前需要要安装相应的软件依赖包
interactive-timeout
4.docker运行mysql的优缺点
4.1 优点
关于这个优点，无脑响应就是docker的相关优势了。
1.部署方便
对于开发而言，搭建环境往往会耗费掉我们好几个小时的时间，而且其中一个小问题可能需要找很久才能解决。而有了容器以后，这些都变的非常容易，你的开发环境就只是一个或者几个容器镜像的地址，最多再需要一个控制部署流程的执行脚本。或者进一步将你的环境镜像以及镜像脚本放入一个git项目，发布到云端，需要的时候将它拉到本地就可以了。
2.部署安全
当我们收到一个bug反馈的时候，很多时候心里的第一反应一定是“我本地是好的呀”！这种情况的发生就在于环境的不一致，我们在开发过程中的调试往往不能保证其他环境的问题，但是我们却要为此买单，这是一件令人苦恼的事情。有了容器以后，这将很少发生。我们可以通过容器技术将开发环境和测试环境以及生产环境保持版本的依赖上的统一，保证代码在一个高度统一的环境上执行。而测试环境的统一，也同样能解决CI流程对环境的要求。
分布式技术和扩容需求日益增长的今天，如果运维能够使用容器技术来进行环境的部署，不仅仅在部署时间上节省不少，也能把很多因为人工配置环境产生的失误讲到最低。
3.隔离性好
不管是开发还是生产，往往我们一台机器上可能需要跑多个服务，而服务各自需要的依赖配置不尽相同，假如说两个应用需要使用同一个依赖，或者两个应用需要的依赖之间会有一些冲突，这个时候就很容易出现问题了。所以同一台服务器上不同应用提供的不同服务，最好还是将其隔离起来。而容器在这方面有天生的优势，每一个容器就是一个隔离的环境，你对容器内部提供服务的要求，容器可以自依赖的全部提供。这种高内聚的表现可以实现快速的分离有问题的服务，在一些复杂系统中能够实现快速排错和及时处理。(需要说明的是，这个隔离性只是相对于服务器比较的，虚拟技术要拥有更好的隔离性)
4.快速回滚
容器之前的回滚机制，一般需要基于上个版本的应用环境重新部署，且替换掉目前的问题版本。在最初的时代，可能是一套完整的开发到部署的流程，而执行这一套流程往往需要很长的时间，在基于git 的环境中，可能是回退某个历史的提交，然后重新部署。这些跟容器技术相比都不够快，而且可能会引发新的问题(因为是基于新版本的修改)。而容器技术天生带有回滚属性，因为每个历史容器或者镜像都会有保存，而替换一个容器或者某个历史镜像是非常快速和简单的。
5.成本低
在容器出现之前，我们往往构建一个应用就需要一台新的服务器或者虚拟机，服务器的购置成本和运维成本都很高，而虚拟机需要占用很对不必要的资源，相比之下，容器技术是小巧轻便的多，只需要给容器内部构建应用需要的依赖就可以，这也是容器技术发展迅速的主要原因。
4.2 缺点
1.数据安全问题
不要将数据储存在容器中，这也是 Docker 官方容器使用技巧中的一条。容器随时可以停止、或者删除。当容器被rm掉，容器里的数据将会丢失。为了避免数据丢失，用户可以使用数据卷挂载来存储数据。
但是容器的 Volumes 设计是围绕 Union FS 镜像层提供持久存储，数据安全缺乏保证。如果容器突然崩溃，数据库未正常关闭，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。
2.性能问题
大家都知道，MySQL 属于关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 MySQL 的读写性能。
在一次Docker应用的十大难点专场上，某国有银行的一位架构师也曾提出过：“数据库的性能瓶颈一般出现在IO上面，如果按 Docker 的思路，那么多个docker最终IO请求又会出现在存储上面。现在互联网的数据库多是share nothing的架构，可能这也是不考虑迁移到 Docker 的一个因素吧”。
其实也有相对应的一些策略来解决这个问题，比如：
1）数据库程序与数据分离
如果使用Docker 跑 MySQL，数据库程序与数据需要进行分离，将数据存放到共享存储，程序放到容器里。如果容器有异常或 MySQL 服务异常，自动启动一个全新的容器。另外，建议不要把数据存放到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比较大。
2）跑轻量级或分布式数据库
Docker 里部署轻量级或分布式数据库，Docker 本身就推荐服务挂掉，自动启动新容器，而不是继续重启容器服务。
3）合理布局应用
对于IO要求比较高的应用或者服务，将数据库部署在物理机或者KVM中比较合适。目前腾讯云的TDSQL和阿里的Oceanbase都是直接部署在物理机器，而非Docker 。
3.状态问题
在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。
Docker 快速扩展的一个重要特征就是无状态，具有数据状态的都不适合直接放在 Docker 里面，如果 Docker 中安装数据库，存储服务需要单独提供。
目前，腾讯云的TDSQL（金融分布式数据库）和阿里云的Oceanbase（分布式数据库系统）都直接运行中在物理机器上，并非使用便于管理的 Docker 上。
4.资源隔离方面
资源隔离方面，Docker 确实不如虚拟机KVM，Docker是利用Cgroup实现资源限制的，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。如果其他应用过渡占用物理机资源，将会影响容器里 MySQL 的读写效率。
需要的隔离级别越多，获得的资源开销就越多。相比专用环境而言，容易水平伸缩是Docker的一大优势。然而在 Docker 中水平伸缩只能用于无状态计算服务，数据库并不适用。
4.3 适合mysql容器化运行的场景
1）对数据丢失不敏感的业务（例如用户搜索商品）就可以数据化，利用数据库分片来来增加实例数，从而增加吞吐量。
2）docker适合跑轻量级或分布式数据库，当docker服务挂掉，会自动启动新容器，而不是继续重启容器服务。
3）数据库利用中间件和容器化系统能够自动伸缩、容灾、切换、自带多个节点，也是可以进行容器化的。
典型案例：同程旅游、京东、阿里的数据库容器化都是不错的案例，大家可以自行去查看。
参考文档：
说明：本文内容除实操部分，其余内容皆为选自别的技术文章，非原创，如侵权请联系我删除。
