cassandra 数据备份
- 作者: 你在弄啥咧
- 来源: 51数据库
- 2020-09-30
在mongodb的官方上search mongodump没有相应的资料，自己就在shell命令行里面 ：
/data/mongodb-linux-x86_64-1.6.0/bin/mongodump --help 了一把， 自己来测试了，测试总结如下：
备份本机mongodb到/tmp/bakup目录下面：[root@localhost csf]# /data/mongodb-linux-x86_64-1.6.0/bin/mongodump -h 192.168.0.39:10001 -d csf -o /backup/mongodb
将/tmp/backup 下面的文件导入数据库：[root@localhost csf]#/data/mongodb-linux-x86_64-1.6.0/bin/mongorestore -h 192.168.0.39:10001 -d csf -drop --directoryperdb /backup/mongodb/csf/
【注释】--drop参数，有此参数，则表示，先删除所有的记录，然后恢复。如无此参数，则恢复备份时候的数据，备份之后新增加的数据依然存在；/backup/mongodb则是备份文件存放路径
在大数据时代，企业的应用带来了大量的数据，它们可能具有结构化、半结构化或非结构化的性质。此外，应用程序开发周期短和可用性强都是他们要考虑的关键问题。考虑到这些应用程序的要求，在下一代平台3应用程序中，企业必须超越传统的关系数据库（iaas或基于云计算paas）。在nosql数据库中，像mongodb现在就被采用了，同时又对这些下一代应用程序的企业进行了评估（如电子商务、内容管理等）。mongodb提供了动态模式，通过自动分片易扩展、读写一致性和在内置中进行复制的功能。
mongodb数据库具有本地复制的功能，同时满足可用性的需求。然而，数据保护要求可伸缩的时间点备份和恢复需要得到很好的解决。对于可靠的数据保护，企业需要备份和复制！没有时间点的备份，组织会由于人为的错误、逻辑混乱和其他操作的失败导致有丢失数据的风险。传统的备份解决方案是建立在关系数据库中，使用共享存储和acid事务模型，来解决结构化平台2应用程序的要求而建的。不幸的是，他们不足以解决平台 3 应用程序和分布式的数据库（本地存储、 最终一致性和基础设施的弹性性质）的时间点备份要求。有几个备用的基于脚本的解决方案（例如地层等），企业正在使用填补数据来保护缩短差距，但这些解决方案充其量算是次优的。
手动脚本解决方案
这些解决方案利用本地mongodb快照工具和脚本将数据传输到辅助存储。（通过 mongodump) 脚本自定义的每个 mongodb 集群和需要业务作出了重大努力，以适应任何拓扑更改 （例如添加或删除节点到 mongodb 数据库） 或扩大规模。此外，这些脚本不适应失败场景，比如失败的一个节点（一级或二级）或间歇性的网络问题。最后，恢复（“备份”）的最重要的价值是一个手动过程。因此，耗费时间（导致很高的应用程序停机时间），并包含脚本中的任何 bug 数据丢失风险。总的来说，这些解决方案工作在mongodb环境中很小和一些允许在应用程序中丢失的数据。这些解决方案所面临的一些关键问题是：
对分片配置的企业备份解决方案的不足；
当快照被取时，数据库需要脱机；
在节点故障和其他基础设施故障下，备份和恢复都失败了；
恢复过程是手动的并且需要验证，从而增加恢复时间；
收集级的恢复需要耗时的手动恢复；
恢复与不同的测试/开发的拓扑（切分 → 分片）刷新是不可用的。
mongodb支付备份和恢复(又名“mms”)
mongodb（公司）本身提供了一些备份mongodb数据库的方法。企业可以选择从一个管理备份提供(mms)运行在公共云，或如果他们支付 mongodb 的客户，他们可能以部署本地备份服务为前提。除了成本过高，在公共云上管理备份服务存储的客户数据。对于部署 mongodb 为前提，在 wan 上备份数据传输可能无法为客户工作，并且海需要为客户保持他们对数据内部的敏感度。此外，还有重要的数据来限制每个碎片去使用这项服务。
使用mongodb部署备份服务是有可能的，但部署和实施过于复杂。企业需要部署8台服务器，附加数据库（额外的许可证）和 6-9x存储容量。总的来说，部署备份服务是一个理论上的解决方案，带来了显著的capex和opex投资：
部署多个数据库的复杂性；
额外的基础设施成本；
授权额外的mongodb节点成本；
当节点失败时，带来备份失败的风险；
独立的mongodb数据库备份基础设施。
实现企业客户的数据保护要求，进入了新兴的下一代分布式数据库的时代（键值、图形、文档库等），并且解决上述方案的局限性。datos io建造了产业界首次扩展数据保护软件产品，使平台3应用程序能部署到分布式和云数据库上，如mongodb和apache cassandra。datos io解决方案是刚刚兴起的下一代应用程序，迎合了业主和devops的应用需求，并解决了部署和管理保护基础设施操作所带来的一切麻烦。最重要的是，它是一个可靠的和可扩展的解决方案，即使在使用节点失败的场景下，也会通过最小化恢复时间获得最优的性能。
/data/mongodb-linux-x86_64-1.6.0/bin/mongodump --help 了一把， 自己来测试了，测试总结如下：
备份本机mongodb到/tmp/bakup目录下面：[root@localhost csf]# /data/mongodb-linux-x86_64-1.6.0/bin/mongodump -h 192.168.0.39:10001 -d csf -o /backup/mongodb
将/tmp/backup 下面的文件导入数据库：[root@localhost csf]#/data/mongodb-linux-x86_64-1.6.0/bin/mongorestore -h 192.168.0.39:10001 -d csf -drop --directoryperdb /backup/mongodb/csf/
【注释】--drop参数，有此参数，则表示，先删除所有的记录，然后恢复。如无此参数，则恢复备份时候的数据，备份之后新增加的数据依然存在；/backup/mongodb则是备份文件存放路径
在大数据时代，企业的应用带来了大量的数据，它们可能具有结构化、半结构化或非结构化的性质。此外，应用程序开发周期短和可用性强都是他们要考虑的关键问题。考虑到这些应用程序的要求，在下一代平台3应用程序中，企业必须超越传统的关系数据库（iaas或基于云计算paas）。在nosql数据库中，像mongodb现在就被采用了，同时又对这些下一代应用程序的企业进行了评估（如电子商务、内容管理等）。mongodb提供了动态模式，通过自动分片易扩展、读写一致性和在内置中进行复制的功能。
mongodb数据库具有本地复制的功能，同时满足可用性的需求。然而，数据保护要求可伸缩的时间点备份和恢复需要得到很好的解决。对于可靠的数据保护，企业需要备份和复制！没有时间点的备份，组织会由于人为的错误、逻辑混乱和其他操作的失败导致有丢失数据的风险。传统的备份解决方案是建立在关系数据库中，使用共享存储和acid事务模型，来解决结构化平台2应用程序的要求而建的。不幸的是，他们不足以解决平台 3 应用程序和分布式的数据库（本地存储、 最终一致性和基础设施的弹性性质）的时间点备份要求。有几个备用的基于脚本的解决方案（例如地层等），企业正在使用填补数据来保护缩短差距，但这些解决方案充其量算是次优的。
手动脚本解决方案
这些解决方案利用本地mongodb快照工具和脚本将数据传输到辅助存储。（通过 mongodump) 脚本自定义的每个 mongodb 集群和需要业务作出了重大努力，以适应任何拓扑更改 （例如添加或删除节点到 mongodb 数据库） 或扩大规模。此外，这些脚本不适应失败场景，比如失败的一个节点（一级或二级）或间歇性的网络问题。最后，恢复（“备份”）的最重要的价值是一个手动过程。因此，耗费时间（导致很高的应用程序停机时间），并包含脚本中的任何 bug 数据丢失风险。总的来说，这些解决方案工作在mongodb环境中很小和一些允许在应用程序中丢失的数据。这些解决方案所面临的一些关键问题是：
对分片配置的企业备份解决方案的不足；
当快照被取时，数据库需要脱机；
在节点故障和其他基础设施故障下，备份和恢复都失败了；
恢复过程是手动的并且需要验证，从而增加恢复时间；
收集级的恢复需要耗时的手动恢复；
恢复与不同的测试/开发的拓扑（切分 → 分片）刷新是不可用的。
mongodb支付备份和恢复(又名“mms”)
mongodb（公司）本身提供了一些备份mongodb数据库的方法。企业可以选择从一个管理备份提供(mms)运行在公共云，或如果他们支付 mongodb 的客户，他们可能以部署本地备份服务为前提。除了成本过高，在公共云上管理备份服务存储的客户数据。对于部署 mongodb 为前提，在 wan 上备份数据传输可能无法为客户工作，并且海需要为客户保持他们对数据内部的敏感度。此外，还有重要的数据来限制每个碎片去使用这项服务。
使用mongodb部署备份服务是有可能的，但部署和实施过于复杂。企业需要部署8台服务器，附加数据库（额外的许可证）和 6-9x存储容量。总的来说，部署备份服务是一个理论上的解决方案，带来了显著的capex和opex投资：
部署多个数据库的复杂性；
额外的基础设施成本；
授权额外的mongodb节点成本；
当节点失败时，带来备份失败的风险；
独立的mongodb数据库备份基础设施。
实现企业客户的数据保护要求，进入了新兴的下一代分布式数据库的时代（键值、图形、文档库等），并且解决上述方案的局限性。datos io建造了产业界首次扩展数据保护软件产品，使平台3应用程序能部署到分布式和云数据库上，如mongodb和apache cassandra。datos io解决方案是刚刚兴起的下一代应用程序，迎合了业主和devops的应用需求，并解决了部署和管理保护基础设施操作所带来的一切麻烦。最重要的是，它是一个可靠的和可扩展的解决方案，即使在使用节点失败的场景下，也会通过最小化恢复时间获得最优的性能。
推荐阅读
