企业官网建设流程全解析

简介：Oracle官方出品的MySQL 8.0数据库管理员Activity Guide实验手册，是一份面向数据库管理员和运维人员的实践型培训资料。手册由Oracle大学讲师团队编写，可配合Oracle官方课程使用，通过分章节的实验练习，帮助读者系统掌握MySQL 8.0的安装配置、备份恢复、性能优化、高可用方案以及复制拓扑搭建等核心技能；对希望夯实企业级MySQL运维能力的初中级DBA尤为适用，练习多基于真实运维场景设计，覆盖环境准备、日常监控到故障处理等完整链路。资源为单个PDF文件，压缩包大小5.86MB，目录按课程章节组织，涵盖从MySQL介绍、安装升级到备份恢复、复制等高阶主题的完整实验流程，并附有课程实验环境说明与安全凭证指引，每个练习包含目标、操作步骤与预期结果，可快速定位到对应练习。目前已有140人学习下载。内容重点覆盖Docker容器中运行MySQL、角色管理与密码策略增强、InnoDB存储引擎改进等新版特性，也包括半同步复制与组复制等高级复制技术，以及数据持久性、灾难恢复和优化器增强的实践指导；每个实验均配有明确的操作步骤和验证思路，部分练习还提供了解答环节，能够帮助管理员在真实业务场景中构建高可用架构，并制定更可靠的数据备份与灾难恢复计划。总体来看，这份实验手册适合希望通过动手实践来理解和掌握MySQL 8.0日常运维要点的读者。

1. 拿 MySQL 8.0 实验手册练手：先把 DBA 的手感找回来

MySQL 8.0 上线这些年，很多老 DBA 还在用 5.7 的习惯做事：账号用 mysql_native_password、复制看位点、备份全靠 mysqldump 一把梭。8.0 的默认认证插件、GTID 复制、数据字典这些变化，不实际操作一遍根本记不住。这份 ActivityGuide 实验手册，说白了一件事：让你在 Docker 容器里把 8.0 的管理操作从头到尾跑一遍，主从复制、备份恢复、性能排查都有现成步骤，照着敲就能出结果。适合两类人：刚接手 MySQL 运维、想在测试环境练手的初级 DBA，以及被生产环境 5.7 绑住、想快速了解 8.0 行为变化的熟手。有一点先说在前面：手册里的命令在 8.0 官方镜像里跑得通，但直接往生产环境抄之前，参数得按你自己的机器改。

2. 把实验环境跑起来：Docker 部署 MySQL 8.0 的镜像选型与初始化参数

2.1 为什么用 Docker 而不是本地二进制包

ActivityGuide 里以 MySQL 8.0 为主版本，大量实验涉及多实例操作，比如主从复制最少要两个节点、MGR 要三个节点。本地装二进制包也能做，但每台机器只能跑一个实例，想同时起三个 8.0 就得折腾多实例目录、不同端口、不同 socket，光配目录权限就够消耗耐心。

我的习惯是用 Docker 官方镜像mysql:8.0。单机多实例互相不干扰，容器之间走自定义网络还能直接用服务名互相访问，复制拓扑的搭建明显省事。另一个优势是环境可丢弃——实验手册里不少操作本身有破坏性，比如删库、清空 binlog、模拟主库宕机，容器不合适了直接删了重建，几十秒又是一套干净环境。

用 Docker 跑 MySQL 有一个容易被忽视的点：容器是精简版操作系统，默认不装 vi 这类编辑器，且没有 systemd，mysql 服务由容器的 entrypoint 管理。这意味着你在容器里改完配置文件后，不能用systemctl restart mysqld，要重启只能重启容器。这个差异别看小，手动执行mysqld命令的时候很容易翻车。

2.2 初始化参数：一次性把容器参数配到位

启动 MySQL 8.0 容器，常见的做法是直接把配置写在宿主机挂载文件里。下面是我起实验环境最常用的一条命令。

mkdir -p /data/mysql/data /data/mysql/config /data/mysql/logs cat > /data/mysql/config/my.cnf <<'EOF' [mysqld] server_id = 1 character_set_server = utf8mb4 collation-server = utf8mb4_0900_ai_ci port = 3306 gtid_mode = ON enforce_gtid_consistency = ON binlog_format = ROW log_bin = mysql-bin skip_name_resolve = ON default_authentication_plugin = caching_sha2_password EOF docker run -d \ --name mysql-8.0 \ -p 3306:3306 \ -v /data/mysql/data:/var/lib/mysql \ -v /data/mysql/config/my.cnf:/etc/mysql/conf.d/my.cnf \ -e MYSQL_ROOT_PASSWORD=Root@123456 \ -e TZ=Asia/Shanghai \ mysql:8.0

这段配置的关键逻辑：先把配置目录和文件准备好，再启动容器。gtid_mode = ON和enforce_gtid_consistency = ON这两行是一起开的，只开前者不开后者，后面做主从复制时部分语句会报错，这是手册实验的基础配置。binlog_format = ROW适配 8.0 默认的复制模式，skip_name_resolve避免客户端反向解析拖慢连接。

有几个参数值得单独说。character_set_server和collation-server建议对齐成同一个字符集体系，8.0 默认的utf8mb4_0900_ai_ci和 5.7 时代的utf8mb4_general_ci排序规则有差异，手册里如果涉及字符集对比实验，直接用 0900 系列可以少踩一个坑。default_authentication_plugin指定了caching_sha2_password，这是 8.0 默认的认证插件，如果你的客户端是 5.7 时代的老版本，这里先留个印象，后面避坑章节会展开说。

-e MYSQL_ROOT_PASSWORD是容器第一次初始化时创建 root 账号用的，一旦数据目录初始化完成，这个参数就失效了。之后改密码要用 SQL 语句或者mysqladmin操作。

2.3 连接方式：别老盯着 TCP，socket 连接也是关键

容器起来之后，很多人习惯用宿主机上装的 MySQL 客户端连，或者直接docker exec -it mysql-8.0 mysql -uroot -p进容器。这两种方式背后对应的是 TCP 连接和 socket 连接，实验手册里涉及连接方式的部分非常多。

在容器里执行mysql -uroot -p不带-h参数时，客户端默认走/var/run/mysqld/mysqld.sock这个 socket 文件。如果你在宿主机直接敲mysql -uroot -p（宿主机也装了客户端），它找的是宿主机的/tmp/mysql.sock，这时大概率报ERROR 2002 (HY000): Can't connect to local MySQL server through socket。这个报错和「连接不上」是两回事，其实服务端好好的，只是客户端找错了 socket 路径。更省事的做法是用mysql -h 127.0.0.1 -P 3306 -uroot -p强制走 TCP。

docker exec -it mysql-8.0 mysql -uroot -p \ -e "SELECT @@server_id, @@port, @@gtid_mode, @@binlog_format;"

这条命令用来确认容器内配置生效情况。-e参数直接执行 SQL 并退出，不回显状态栏。输出里@@server_id应该是1，@@gtid_mode应该是ON，@@binlog_format应该是ROW。哪一项和预期不符，回去检查my.cnf是否挂载成功——用docker exec mysql-8.0 cat /etc/mysql/conf.d/my.cnf看一眼文件内容就知道问题了。

3. 搭一组 GTID 主从复制：复制拓扑实验落地与验证

3.1 为什么实验手册里推 GTID 而不是传统位点

MySQL 8.0 的复制体系里，GTID 已经是事实标准。传统基于日志文件的复制，从库要记住主库的binlog 文件名 + 偏移量（即 File 和 Position），两次切换后很容易搞混。手工配置 CHANGE MASTER 时少写一个数字，复制就可能错位。

GTID 的思路不一样：每个事务有一个全局唯一 ID（由server_uuid:事务序号组成），从库只要说自己同步到哪个 GTID，主库就知道接下来发哪些事务。这个特性在 MySQL 5.6 引入，8.0 里默认开启并去掉了传统复制的很多限制。ActivityGuide 里所有涉及复制的实验场景，基本都以 GTID 为前提。

对做实验的人来说，GTID 最大的实际价值是重建从库极其方便。传统方式要从SHOW MASTER STATUS里抄 File 和 Position，GTID 方式只需要SET GLOBAL gtid_purged或者直接让从库自动追平，少抄两个值就少一个出错点。下表是两种方式的核心差异：

3.2 从零搭一主一从：CHANGE MASTER 的正确姿势

我在实验环境里搭一主一从，习惯先把主库配置写好，再复制一份给从库，只改server_id和端口。下面是完整的搭建过程，主库沿用上一章的容器，另起一个从库容器。

# 1. 启动从库容器，端口映射为 3307，server_id 改为 2 docker run -d \ --name mysql-8.0-slave \ -p 3307:3306 \ -v /data/mysql-slave/config/my.cnf:/etc/mysql/conf.d/my.cnf \ -e MYSQL_ROOT_PASSWORD=Root@123456 \ mysql:8.0 # 2. 在主库创建复制专用账号 docker exec -it mysql-8.0 mysql -uroot -pRoot@123456 \ -e "CREATE USER 'repl'@'%' IDENTIFIED BY 'Repl@123456';" docker exec -it mysql-8.0 mysql -uroot -pRoot@123456 \ -e "GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%';" # 3. 在从库执行 CHANGE MASTER（注意区分 MASTER 和 SOURCE 两个时代的语法差异） docker exec -it mysql-8.0-slave mysql -uroot -pRoot@123456 \ -e "CHANGE MASTER TO \ MASTER_HOST='mysql-8.0', \ MASTER_PORT=3306, \ MASTER_USER='repl', \ MASTER_PASSWORD='Repl@123456', \ MASTER_AUTO_POSITION=1;"

第 3 步的MASTER_AUTO_POSITION=1是 GTID 复制的核心参数，告诉从库用 GTID 自动定位同步点，不需要手动指定MASTER_LOG_FILE和MASTER_LOG_POS。如果这一项设为 0，就是传统位点复制模式。

注意这里从库是通过容器网络里的服务名mysql-8.0访问主库的，不是127.0.0.1。我第一遍搭的时候在这里栽过：从库容器和主库容器不在同一个网络，MASTER_HOST写127.0.0.1，结果从库连的是自己，复制线程一直报连接被拒。解决方式是启动从库容器时加--network=container不现实，正确做法是创建一个自定义网桥。

docker network create mysql-lab # 重建主从容器，都加入 mysql-lab 网络

3.3 验证复制状态：别只看Slave_IO_Running和Slave_SQL_Running

复制搭完以后，验证环节有个常见的误区：只知道看SHOW REPLICA STATUS里的两个 Yes。更实用的做法是看Retrieved_Gtid_Set和Executed_Gtid_Set是否一致，再用SHOW MASTER STATUS对比主库的Executed_Gtid_Set。

docker exec -it mysql-8.0-slave mysql -uroot -pRoot@123456 \ -e "SHOW REPLICA STATUS\G" | grep -E "Slave_IO_Running|Slave_SQL_Running|Retrieved_Gtid_Set|Executed_Gtid_Set|Last_IO_Errno|Last_SQL_Errno"

在 8.0.22 之前的版本，这个命令是SHOW SLAVE STATUS，ActivityGuide 对应的 8.0 版本已经全部换成SHOW REPLICA STATUS。如果你在旧资料里看到SLAVE字样，别直接照抄，MySQL 8.0 里SLAVE相关的关键词已逐步废弃，部分版本还会把SLAVE当作语法错误处理。

验证复制是否真正工作的方法很简单：在主库建一个测试表插入数据，再到从库查。不要只在主库执行 DDL，一定要插入几条数据再查，因为 DDL 复制和 DML 复制走的路径不完全一样，后者更能反映 binlog 解析和 SQL 线程执行的完整性。

4. 高可用与备份恢复：ActivityGuide 里含金量最高的实验组合

4.1 备份选型：逻辑备份和物理备份不是二选一

ActivityGuide 里备份恢复相关的实验铺得比较开，既有mysqldump这种逻辑备份，也有 MySQL 8.0 企业版才有的物理备份工具（如 mysqlbackup）。实验手册面向 DBA 角色，核心目的不是让你记住工具用法，而是建立「备份策略必须和恢复目标挂钩」的意识。

逻辑备份导出的是 SQL 语句，跨版本迁移友好，但速度慢；物理备份直接拷贝数据文件，速度快，但要求目标版本高度一致。对实验环境来说，我只用逻辑备份，因为数据量小，且经常要跨容器做恢复演练。对生产环境，通常两套都保留：每天逻辑备份解决误删数据，定期物理备份解决整库崩溃。

4.2 用 mysqldump 做一次完整恢复演练

这里的关键是：模拟一次「误删数据 → 恢复到删除前」的完整闭环。常见做法是定期全量备份 + binlog 增量衔接。以下是完整命令序列。

# 1. 在主库执行全量逻辑备份（--single-transaction 保证 InnoDB 一致性快照） docker exec mysql-8.0 mysqldump -uroot -pRoot@123456 \ --single-transaction \ --source-data=2 \ --all-databases > /data/backup/full_backup_$(date +%F).sql # 2. 模拟误删操作：删除一张业务表 docker exec mysql-8.0 mysql -uroot -pRoot@123456 \ -e "DROP TABLE sakila.film;" # 3. 把全量备份恢复到从库（从库此时可以充当恢复演练环境） docker exec mysql-8.0-slave mysql -uroot -pRoot@123456 \ -e "SOURCE /tmp/full_backup.sql;"

执行逻辑上有个细节：--single-transaction配合--source-data=2（即旧版本的--master-data=2）时，备份导出的一致性快照包含当时对应的 binlog 位置，这个位置记录在备份文件开头的注释块里。恢复时先恢复全量备份，再用 binlog 把全量备份之后产生的增量操作追回来，才能到达崩溃前的状态。

# 4. 从备份文件头部获取 binlog 位置 head -80 /data/backup/full_backup_$(date +%F).sql | grep -A2 "CHANGE MASTER TO" | grep "MASTER_LOG" # 5. 将从库指向主库并追平增量 binlog（恢复后的从库不应继续原复制关系，需先重置） docker exec mysql-8.0-slave mysql -uroot -pRoot@123456 \ -e "RESET REPLICA ALL;"

这里最容易踩的坑是：全量备份恢复后，从库原本的复制关系还在，如果你直接尝试START REPLICA，从库会用原 GTID 集合跳过一堆事务，导致恢复到的时间点对不上。我一般恢复演练前先RESET REPLICA ALL，切断原有复制，等增量追完再判断要不要重建复制关系。

4.3 高可用切换：主备切换实验的边界条件

手册里高可用部分通常会引导你模拟主库宕机、从库提升为主库的完整流程。这个实验在 MySQL 8.0 下比 5.7 更顺手，因为 GTID 让日志位置的追踪不再依赖记忆。

模拟主库宕机的典型操作顺序：

# 1. 停止主库容器模拟宕机 docker stop mysql-8.0 # 2. 在从库上执行提升操作 docker exec mysql-8.0-slave mysql -uroot -pRoot@123456 \ -e "STOP REPLICA;" docker exec mysql-8.0-slave mysql -uroot -pRoot@123456 \ -e "RESET REPLICA ALL;" # 3. 将业务流量切到原从库（此处仅验证步骤，实际需配合应用层切换） docker exec mysql-8.0-slave mysql -uroot -pRoot@123456 \ -e "SELECT @@hostname, @@server_id, @@read_only;"

执行切换前有一个容易忽略的动作：确认原从库的read_only是否为 ON。如果从库一直以read_only模式运行，提升为主库后必须显式关闭，否则业务写入会直接报ERROR 1290 (HY000): The MySQL server is running with the --read-only option。

另一个需要留意的是：真正生产环境的选主有复杂的权重和半同步判断，实验环境里手动STOP REPLICA没问题，但不要把这个简化做法直接搬到生产。生产环境做计划切换之前，必须先确认从库没有延迟，否则可能丢数据。

5. 避坑记录：跑 ActivityGuide 时最容易翻车的五个点

5.1 字符集报错[ERR] 1071 - Specified key was too long

现象：在创建带 varchar 字段的索引进度里，执行CREATE TABLE或加索引时报[ERR] 1071 - Specified key was too long; max key length is 767 bytes。原因：8.0 里如果表默认字符集是 utf8mb4，一个字符最多 4 字节，varchar(255) 做前缀索引需要255 * 4 = 1020字节，超过 InnoDB 老版本 767 字节的单列索引上限；但 8.0 默认单列索引上限是 3072 字节，你遇到这个报错，往往是复制了 5.7 时代的建表语句，且建表时没有指定ROW_FORMAT=DYNAMIC。解决：建表时显式指定行格式。

CREATE TABLE t ( col_a varchar(255), KEY idx_col_a (col_a) ) ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT CHARSET=utf8mb4;

5.2ERROR 2002：socket 路径对不上

现象：容器里 MySQL 运行正常，宿主机执行mysql -uroot -p报ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'。原因：MySQL 客户端在宿主机找不到 socket 文件，实际 socket 在容器的/var/run/mysqld目录里。跳过 TCP 直连时，宿主机上的 socket 自然不存在。解决：客户端强制用 TCP 方式连接，加-h 127.0.0.1 -P 3306参数；或者挂载时指定 socket 路径。

5.3caching_sha2_password导致旧客户端连不上

现象：MySQL 8.0 启动正常，但程序或旧版客户端连接时报Authentication plugin 'caching_sha2_password' cannot be loaded。原因：8.0 默认认证插件是caching_sha2_password，5.7 时代的客户端只支持mysql_native_password。解决：实验环境里最省事的做法是给账号指定兼容认证插件，生产环境建议升级客户端。

CREATE USER 'old_client'@'%' IDENTIFIED WITH mysql_native_password BY 'Test@123456';

5.4 从库 SQL 线程报错：GTID 事务冲突

现象：从库SHOW REPLICA STATUS\G里Last_SQL_Errno为 1062，Last_SQL_Error提示主键重复，SQL 线程停止。原因：手工往从库写过数据，或者从库上曾经执行过主库还没执行的事务，导致 GTID 集合和主库不一致，重复执行了相同事务。解决：先确认该事务在从库是否已存在，如果确认是实验操作引入的脏数据，可以跳过该事务：

STOP REPLICA; SET GLOBAL sql_replica_skip_counter = 1; START REPLICA;

注意的是sql_replica_skip_counter只适合临时跳过，跳过之后务必对比主从 GTID 集合，确认没有积累更多差异。

5.5 Docker 容器重启后数据丢失

现象：容器运行期间插入的数据在重启容器后消失，数据目录是新的。原因：没有将容器内/var/lib/mysql挂载到宿主机持久化目录。解决：启动容器时加-v /data/mysql/data:/var/lib/mysql，同时在停止容器前用FLUSH TABLES WITH READ LOCK或正常停库，避免文件损坏。

docker stop mysql-8.0 docker start mysql-8.0 # 如果数据目录未挂载，数据会初始化成全新库

6. 一个值得养成的习惯：正式实验前先给 MySQL 环境留一份「后悔药」

ActivityGuide 里很多实验是不可逆的：DROP 数据库、RESET REPLICA ALL、清理二进制日志，每一步点下去都没有后悔药。我见过不止一个人把主从复制实验做到一半，然后发现从库的数据被自己清掉了，只好从头再搭一遍。

现在我的习惯变了：任何破坏性实验之前，先跑一条命令，把当前环境打一个标签快照。

# 在宿主机执行，给当前数据目录打一个快照标签 docker commit -m "before copy lab" mysql-8.0 mysql-8.0-snapshot:copy-lab

这条命令会把容器当前的文件系统状态保存成一个新的镜像。后续实验做砸了，直接基于这个镜像重新起容器，数据目录就是快照时刻的状态，全程不用重装 MySQL，不用重新初始化，几十秒回到实验前。

如果是多节点的复制拓扑，我会先把所有节点的容器都停掉，再统一打快照，然后按原顺序启动。比如一主一从，主从数据是不同阶段的状态，分别打快照，恢复时按原拓扑关系把两个容器重新拉起来，然后在从库执行：

CHANGE MASTER TO MASTER_HOST='mysql-8.0', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='Repl@123456', MASTER_AUTO_POSITION=1; START REPLICA;

容器环境下做实验有一个天然优势：快照成本极低。这比在物理机上做任何备份都快，属于镜像文件系统层面的秒级操作。从那以后，我每次做破坏性实验之前都强制走一遍这一步，浪费十秒钟，换来的是反复重试的自由。希望帮到你。

本文还有配套的精品资源，点击获取