8.4 Swarm存储卷应用

任务一：探究默认存储卷的局限性

任务目标： 部署一个 MySQL 服务到 Swarm 集群中，使用默认的本地存储卷（Volume），然后通过模拟节点故障，观察数据会发生什么情况。

步骤 1：部署服务

首先，我们来创建一个 MySQL 服务。

docker service create \
--name db_[学号后两位] \
--replicas 1 \
-p [3300+学号后两位]:3306 \
-e MYSQL_ROOT_PASSWORD=root \
--mount source=mysql_data_[学号后两位],target=/var/lib/mysql \
mysql:5.7

部署后，使用 docker service ls 或 docker service ps 命令查看服务状态，确保它已成功运行。

步骤 2：写入测试数据

现在，服务已经运行起来了。让我们连接到数据库，并写入一些测试数据。

1. 使用 Navicat 或其他数据库客户端连接到 MySQL 服务。
2. 创建一个新的数据库，例如 students (字符集 utf8mb4)。
3. 在 students 数据库中创建一个表，例如 cloud23，包含 no 和 name 两个字段。
4. 在表中插入你自己的信息作为测试数据。

步骤 3：查看服务所在节点

执行以下命令，查看我们的 MySQL 服务当前运行在哪个节点上。记下这个节点的主机名。

docker service ps db_[学号后两位]

步骤 4：模拟节点故障（迁移服务）

接下来，我们来模拟当前节点发生故障，Swarm 将服务迁移到另一个健康节点的情况。我们可以通过添加约束（constraint）来强制服务在另一个节点上运行。

# 将下面的“节点主机名”替换成一个与当前运行节点不同的目标节点主机名
docker service update db_[学号后两位] --constraint-add "node.hostname==节点主机名"

执行后，再次查看服务状态，你会发现服务已经被重新调度到了新的节点上。

步骤 5：观察结果

现在，回到 Navicat，刷新一下数据库连接。你会发现，我们刚刚创建的 students 数据库、cloud23 表以及里面的数据，全都消失了！

任务二：使用 NFS 实现持久化存储

任务目标： 既然本地存储卷不可靠，我们需要一个所有节点都能访问的共享存储。在实际工作中，NFS（网络文件系统）是一个简单且高效的选择。让我们用它来解决数据丢失的问题。

步骤 1：准备工作

首先，确保所有 Swarm 节点都安装了 NFS 客户端工具。

在所有节点上执行以下命令：

yum install -y nfs-utils

步骤 2：创建支持 NFS 的存储卷

与任务一不同，这次我们要创建一个特殊类型的存储卷，它连接到 NFS 服务器。

在所有节点上都执行这个命令，以确保每个节点都知道这个 NFS 存储卷的存在：

docker volume create \
--opt type=nfs \
--opt o=addr=192.168.192.205,rw,nolock \
--opt device=:/data/[学号后两位] \
mysql_data_nfs_[学号后两位]

步骤 3：重新创建服务并验证

现在，让我们用新的 NFS 存储卷来重新部署 MySQL 服务。

1. 首先，删除任务一中创建的旧服务：docker service rm db_[学号后两位]

2. 使用与任务一类似的命令重新创建服务，但这次 --mount 的 source 要指向我们新创建的 NFS 存储卷：

   bash

   docker service create \
   --name db_[学号后两位] \
   --replicas 1 \
   -p [3300+学号后两位]:3306 \
   -e MYSQL_ROOT_PASSWORD=root \
   --mount source=mysql_data_nfs_[学号后两位],target=/var/lib/mysql \
   mysql:5.7

3. 重复任务一中的步骤 2，向数据库中写入相同的数据。

4. 重复任务一中的步骤 4，将服务迁移到另一个节点。

5. 再次回到 Navicat 中查看，这次你会发现，即使服务迁移到了新节点，数据依然完好无损！