使用 IBM Spectrum Protect for Linux on Power 备份和还原 MongoDB 数据的方法-6

look_w

• 还原命令
  • 如果还原到最初从中获取备份的相同系统，可使用以下命令：
    dsmc restore image /dev/rhel7_system/data
  • 如果希望将 IBM Spectrum Protect                            镜像还原到不同的系统，需要授权这个新系统，允许它访问原始系统的备份镜像。为此，请执行以下操作：
  • 访问备份起源服务器。通过输入 dsmc 终端命令进入 IBM Spectrum                            Protect shell。
  • 请注意，您的提示符为 tsm>
  • 输入 q access 命令来识别有访问权的节点，或者输入                            q files                            命令来查看所有已备份的文件。set access backup "*" nodeName. set access backup "*" nodeName                            命令列出了包含 nodeName 的能够访问当前节点的备份文件的所有节点。
  • 目标还原服务器能访问备份后，可使用以下命令执行还原：
    dsmc restore image -fromnode=LTMNGO09 /dev/rhel7_system/data /dev/rhel7_system/data
  • 还原 LVM                                后，需要将它重新挂载到文件系统。运行以下命令：
    mount /dev/mapper/<volumeGroup> - <name> <mountPoint> （例如                                mount dev/mapper/rhel7_system-data /data）
    
  • 在该服务器上启动 MongoDB 实例，尝试使用 mongo —port                            <port> 连接到本地 MongoDB                            shell。确认系统在正确的配置下正常运行后，停止 MongoDB                                实例。还原过程的这一阶段可能稍微不同。因为我们拥有相同的服务器，所以只需查看一个副本的备份镜像。在还原时，需要将这个镜像还原回所有副本。完成此任务的两种最简单方法是：
    
    • 使用 IBM Spectrum Protect 还原到一个服务器，使用 copy                                    命令将文件从还原的服务器移动到它的所有副本
    或者，
    
    • 将 IBM Spectrum Protect 代理安装在所有系统上，同时从 IBM Spectrum                                    Protect                                    服务器还原该镜像，以观察复制的服务器。这需要执行前面提及的步骤，以确保副本集中的其他每个节点都能访问备份节点。
    在还原后复制文件的优势在于能减少 IBM Spectrum Protect                                代理的数量。因为我们只需要来自一个系统的备份数据，所以安装的大部分 IBM Spectrum Protect                                代理仅执行还原操作，绝不执行任何备份任务。将文件从还原的备份服务器复制到副本集时，IBM Spectrum                                Protect 服务器执行的工作更少，而且只需在备份服务器上安装 Spectrum Protect 代理。根据                                IBM Spectrum Protect                                的定价套餐，这可能有一定的影响，尤其是在大规模执行还原时。当然，您必须编写一个程序来将文件从还原的服务器中复制并分发到其他服务器，而且需要稍微更多的自定义工作。
    对所有服务器使用                                Spectrum Protect 还原功能可能更加简单。但是，集群中所有系统上都需要有一个 Spectrum                                Protect 代理。Spectrum Protect 服务器上的压力也会增加，因为 MongoDB                                集群中的每个节点都需要直接从该服务器还原 LVM                                镜像。在本文中，我们使用了两种方法，并发现两种方法都很令人满意。
    方法                                1（复制文件）：按照上面的解释，使用 Spectrum Protect                                代理还原到服务器。进入已还原的卷的数据目录，并使用 TCP                                将数据传输到其他服务器。
    scp -r /data/mongo/….. hostname1:/ 例如：
    scp -r /data/mongo root@ltmgo04:/data 然后一定要在文件到达另一个服务器时在这些文件上使用                                chown，以确保文件归运行 MongoDB 的用户（默认为                                    mongod）所有。也可以使用 rsync                                或其他某种文件复制/同步方法在服务器之间传递文件。
    方法 2（在所有服务器上使用                                    IBM Spectrum                                Protect）：在此方法中，需要在所有服务器上安装 Spectrum                                Protect，并运行上面给出的 set access                                方法。需要对拥有自己的副本集的每个成员的每个备份系统运行这些方法。这样，它们就能自由访问该 Spectrum                                Protect                                镜像。然后，可以按照之前提到的所有还原步骤，使用远程还原方法来还原文件系统。然后，应该更改数据目录的所有权，确保它归运行                                MongoDB 的用户所有。
    这个还原过程同样适用于所有 MongoDB 数据服务器和 MongoDB                                配置服务器。mongos                                服务器唯一需要还原的是，放置在要运行它们的服务器上的配置文件。
    既然我们已知道如何备份所有单独的服务器，接下来需要确保按正确顺序启动集群。
    在还原过程的这一阶段，MongoDB                                实例应包含其所有数据并正常运行。然后，应再次关闭 MongoDB 服务，让所有 MongoDB                                服务目前都处于关闭状态。
    接下来，我们将启动 MongoDB                                服务，保持它们运行，确保没有任何错误。这是还原 MongoDB                                实例的启动顺序，与原始启动顺序完全相同。
    首先，必须启动单个副本集的每个成员。需要确保有一个主节点和一个辅助节点，而且它们都能相互通信并将自己识别为同一个副本集的成员。必须对所有不同的副本集执行此操作，并在前进到下一步时保持它们正常运行。
    其次，激活所有副本集后，是时候处理配置服务器了。这些服务器必须在所有                                mongos 实例之前开启。所有 3 个服务器都正常运行后，就可以开始启动 mongos                                实例。保证（永远）不会更改配置服务器的主机名。即使还原到了新的配置服务器，也应该更改它们的主机名，使之与原始                                mongos 配置中的主机名相匹配。
    应该首先启动一个 mongos                                实例，检查日志，确保可以连接到所有配置服务器实例。看到这些操作完成后，通过 mongos 实例连接到 MongoDB                                shell。然后可以运行分片测试，查看数据，确保所有一切都在。如果一切都运行正常，那么您已成功还原一个                                MongoDB 备份，并运行着一个有效的集群。您可以启动想要的任意多个 mongos                                实例，并尽情使用您刚还原的服务器。
    
• 将数据放在何处根据与备份过程相关的各种因素，我们确定 MongoDB                        的数据部分应保留在一个单独的卷组中，并挂载到 /data                        目录。现在，可以将它挂载到现有卷组，但必须是它自己的逻辑卷。我们不想在执行备份时浪费任何空间，而且希望能够轻松地将它挂载到已知位置。                    
  性能考虑因素备份过程中要知道的考虑因素：
  
• 时间 - 时间不是一个重要因素，因为在备份期间 MongoDB                    集群性能没有任何影响。物理备份的吞吐量依赖于基础架构的吞吐量和同时备份的分片数量。
• CPU 性能 - 备份过程中可以观察到更高的 CPU 利用率。执行无压缩备份时，可以看到运行期间的空闲空间比例下降了                    10% 到 20%。最极端的情况是在开启压缩时。我们看到在执行压缩备份时，一些系统的空闲空间比例在短时间内（30 秒）保持在                    0%，这种情况肯定不理想。这些系统在执行备份时确实正在运行，并可能被要求执行查找，如此高的 CPU 利用率可能会导致 MongoDB                    性能瓶颈。但是，我们注意到，在执行压缩备份期间，MongoDB 集群性能没有出现明显下降。显然 CPU                    与网络流量和存储之间达到了某种平衡。应根据每个案例来确定最佳方法。一定要记住，MongoDB 通常不受 CPU 利用率约束。内存空间和磁盘                    I/O 更有可能带来压力。鉴于在我们的测试案例中，备份服务器是一个辅助副本，它仅处理偶尔的读操作，不会处理直接写入操作，所以备份过程使用的                    CPU                    周期应可以忽略不计。根据设计，备份流程是在负载低于主服务器且能快速备份的服务器上执行的，而剩余服务器可用来处理使用高峰期内的请求，并与数据库的剩余部分保持同步，而不需要在备份后再赶上进度。
• MongoDB 性能                    -备份允许所有服务器（包括备份服务器）保持运行并能执行正常任务。这应该不会影响 MongoDB                    的性能，除非在最大压力情况下。备份过程中最大胆的性能权衡措施是禁用某个配置服务器。这意味着 mongos 服务器必须从 2 个而不是 3                    个服务器中检索所有元数据。但是，MongoDB 3.0 版不会扩展到 3                    个配置服务器以上，这意味着拥有更多配置服务器实际上不会提升性能；这更多地是一种冗余措施。配置服务器恢复上线后，它将进入同步模式，以捕获在它离线期间可能发生的任何元数据更改。该操作通常会在几秒内完成，完全不会引起问题。
• 压缩与非压缩备份- 对于 Spectrum Protect Server 的 IBM Power                    版本，可以选择使用压缩和非压缩备份。压缩镜像备份需要更多时间才能完成。

结束语MongoDB 变得越来越流行，并广泛应用于 Power 环境中。IBM Spectrum Protect（以前称为 Tivoli Storage                Manager）是一个成熟、久经考验、战略性的世界级数据保护平台，能帮助所有规模的企业满足其数据保护需求。
本文介绍了使用 IBM Spectrum Protect 备份 MongoDB 数据的方法。如果客户已在其数据中心内建立了 Spectrum                Protect，那么 Spectrum Protect 备份功能将是一个不错的数据保护选项。
这里回顾的备份过程推荐使用 IBM Spectrum Protect 为一个专门用作备份服务器的 MongoDB 副本集成员创建 Linux                文件系统快照。文中定义了设置备份环境的最低要求。列出了对数据和日志文件执行备份的步骤。在执行备份的同时，应用程序可以写入数据，而不会宕机。
使用 IBM Spectrum Protect 还原 MongoDB 数据库的方法也已经过测试和备案。本文包含准备目标文件系统的步骤和发起还原的                IBM Spectrum Protect 命令。推荐的复原选项是使用 IBM Spectrum Protect 恢复一个副本集成员，使用 Linux                命令将数据复制到副本集的其他成员。另一个选项是将 Spectrum Protect 代理安装在所有服务器上，并使用 IBM Spectrum                Protect 还原它们。因此，本文提供了多种选择：我们展示了此解决方案的灵活性，并尽力让客户能确定哪种选项最适合他们的环境。