docker swarm 备份与恢复

备份集群

管理节点将集群状态和管理日志存储在/var/lib/docker/swarm/目录中。在1.13以及更高版本中，此数据包括用于加密raft日志的秘钥。没有该秘钥，将无法恢复集群。

可以使用任何管理者来备份集群。步骤如下：

• 如果集群已经启用自动锁定，则需要解锁秘钥才能从备份恢复集群。如果需要，请取出解锁秘钥，并将其存放在安全的位置。
• 在备份数据之前，停止管理者上的docker，以确保在备份期间不会更改任何数据。不建议热备份，在恢复的时候可能出现不可预测的问题。同时，在备份期间，其它节点将继续产生新的数据的。
• 备份/var/lib/docker/swarm整个目录
• 重新启动管理者

灾难恢复

从备份恢复

按照上述备份集群所述备份集群后，使用以下步骤将数据恢复到新的集群：

• 关闭将要恢复集群的目标主机的docker
• 删除新集群的/var/lib/docker/swarm目录
• 使用备份的内容还原/var/lib/docker/swarm目录
• 在新节点上启动docker。必要时解锁集群。使用docker swarm init --force-new-cluster命令重新初始化群集，以便此节点不尝试连接到作为旧集群的一部分的节点，并且可能不再存在。
• 验证集群的状态是否如预期的那样。
• 如果使用自动锁定，请旋转解锁秘钥。
• 添加管理和工作节点到新的集群，以达到生产能力。
• 在新集群上恢复以前的备份方案

从失去法定人数恢复

集群对故障有弹性，群集可以从任何数量的临时节点故障恢复（机器重新启动或重启时崩溃）或其他瞬态错误。但是，如果集群失去法定人数，集群不能自动恢复。现有工作人员节点上的任务将继续运行，但无法执行管理任务，包括扩展或更新服务，并从群集中加入或删除节点。恢复的最佳方法是将丢失的管理节点重新联机。如果不可能，请继续阅读一些恢复群集的选项。

在N个管理者的集群中，法定人数的管理节点（绝大多数）必须始终可用。如，在有5个管理者的群体中，至少3名必须运作并相互通信。换句话说，群组可以忍受多达（N-1）/ 2个永久性故障，超出了该临界值，凡是涉及到集群管理的请求都无法处理。这些类型的故障包括数据损坏或硬件故障。

如果失去了法定的管理者，就不能管理集群了。如果失去了法定人数，并尝试对集群执行任何管理操作，会发生如下错误：Error response from daemon: rpc error: code = 4 desc = context deadline exceeded

最佳恢复方法是将失去的节点重新联机。如果不能这样做，从此状态恢复的唯一方法是在管理节点上使用--force-new-cluster。这将除去运行该命令的管理者之外的所有管理者。法定人数实现了因为目前只有一个管理者。提升节点为管理者，直到拥有所需数据的管理者。

# From the node to recoverdocker swarm init --force-new-cluster --advertise-addr node01:2377

当运行docker swarm init --force-new-cluster 时，该节点成为管理节点的单节点集群，能够管理和运行服务。管理者拥有以前关于服务和任务的所有信息，工作节点仍然是集群的一部分，服务仍将运行。将需要添加或重新添加管理器节点以实现以前的任务分发，并确保有足够的管理员来维护高可用性并防止丢失法定人数。

强制集群重新平衡

一般来说，是不需要强制集群重新平衡任务。当向集群添加新节点或者可不用节点重新连接到集群，集群不会自动的向空闲节点分配工作负荷的。这是一个设计决策。如果集群为了平衡而将任务定期的转移到不同的节点，会导致使用这些任务的客户端中断。目的是避免扰乱运行的服务，以便在整个集群中实现平衡。当启动新任务时或者运行任务的节点不可用了，这些任务将会被分配到不繁忙的节点上。目的是最终平衡，对终端用户影响最小。

在docker 1.13以及更高版本中，可以使用docker service update --forece 命令强制服务在可用的工作节点之间重新分配其任务。这将导致服务任务重新启动。客户端应用程序可能会中断。如果您已配置，您的服务将使用滚动更新。