挑战
我知道有一些做法，例如仅添加数据库对象，即表和列，从不修改或删除它们
在我工作过的一家公司中，原始数据的滚动窗口大约相当于6个月，占用了10 TB的数据。然后将数据处理为RDBMS格式，该格式花费6 TB的可用数据，约占10年的可报告数据。关键是，大规模的实践根本不可行。存储很昂贵-可能是最大的计算费用。这提供了几个有趣的挑战：
- 备份 -innodb插件很棒，而且很不错，但是备份这么多数据的时间并不实用
- 还原时间 -对于大型数据集-特别是如果您需要复制以在还原后恢复到正常运行状态后可能需要几天甚至几周的时间才能赶上
- 创建/播种新实例 -您在开发/测试中可能要做的工作通常涉及数据集上的ETL（提取，转换和加载）作业。这些需要使用质量检查测试单元进行验证，但这需要以非破坏性的方式进行，以便保留原始生产数据集。在发生灾难时，您可能会愿意花较长的时间进行恢复，但要了解备份是一种保险政策，并且其目的是避免备份，DevOps开发工作流程实质上要求您能够执行恢复或恢复。定期（可能一天多次）复制数据
- 容量 -按照我刚才描述的规模存储大量数据可能会占用大量I / O。您不仅需要解决1-3中描述的问题，而且还需要以不导致生产系统停机或性能下降的方式进行。
尽管在较小规模上可能不需要考虑上述因素，但在较大规模上，这些成为巨大的问题。这意味着定义需求并预测数据集的大小非常重要。
定义要求
因此，您需要定义几个需求：
- RTO-备份的RTO或还原时间目标是数据库备份解决方案的最重要驱动程序之一。虽然一开始它似乎与大多数其他问题都不相关，但是当您询问“如果我使用备份解决方案创建或播种新实例该怎么办？”时，它变得极为相关。在下一节中，我将介绍一些这样做的技术。
- RPO-备份的RPO或还原点目标定义了A）您可以还原的时间（分钟，小时，天，周，月或年）B）不同级别的备份间隔和C）您可以还原的粒度。例如，对于电子邮件数据库，通常需要消息级别备份（还原特定的电子邮件）。同样，您可能会发现几天内的数据完全没有用，因此一年再恢复也没有意义。
- 数据集的大小 -这很重要，因为对于1MB的数据库，大多数备份产品和解决方案都可以实现RTO。但是，对于10TB数据库，您会发现到LTO 3磁带的完整，行级备份可能无法实现RTO，并且可能会干扰RPO，因为备份开始超出您的备份窗口。您不能只对如此大的数据集进行mysqldump，但可能可以避免在1MB数据库上进行。
- 数据库一致性 -使用数据库时，在持续部署，站点可靠性，可伸缩性和高可用性方面产生巨大差异的最后一件事是您对一致性的需求（或缺乏一致性）。共有三种基本类型：即时一致性，即时（JIT）一致性和最终一致性
除了上述主要考虑因素之外，您还需要考虑许可和支持要求（开源或封闭源；内部支持，第三方支持或供应商支持）应用程序/语言要求（许多数据库的连接器可能很重要；您的应用已编译？您可以访问源代码吗？您可以重新编译它，或者由供应商提供吗？或者它以解释语言运行？）政治要求（您的组织仅信任Oracle吗？他们讨厌oracle吗？他们不信任MySql吗？您对MariaDB或Postgres感觉如何？对数据库引擎（innoDB，MyISAM，Blackhole，NDB集群或Spider）有什么看法，以及对历史或兼容性的要求（我们使用PL / SQL长达数年半的代码）是内置在Oracle引擎中的！我们怎么能移植到MariaDB？！？）
所有这些事情（显着）都会影响您可用的工具。
内部数据管理的一些选项
注意：以下内容并非详尽无遗，其他SE用户也应附上其他建议。
出于对通用考虑的考虑，让我为您提供一些解决上述问题的技术。首先，问问自己是否真的需要使用RDBMS，或者是否可以选择使用诸如Hadoop，CouchDB甚至面向对象存储（如swift）之类的非结构化数据。
其次，考虑研究基于云的解决方案。这将一些令人头疼的事情外包了，并将复杂的问题留给了高素质（和有偿）的个人。但是，从规模上看，您会发现这确实会消耗您的预算（云提供商确实会从中获利，并且在一定规模上，您只能自己聘请这些专家，），或者如果您在特定的安全或政治环境下工作需求（阅读：我们不能做云）考虑混合NFS / FibreChannel Filer。这些文件管理器中的大多数文件管理器（例如NetApp，Pure Storage和Tegile的文件管理器）都支持基于增量的快照和克隆技术，对于A）进行备份，B）恢复备份和C）播种新备份非常有用。
在这一点上，我需要指出的是，我不是备份和存储专家，因此在继续研究其他问题（和更绿色的牧场）之前，这个问题的某些部分是我无法完全解决的。
话虽这么说，但这些产品使您可以在数据库下方拍摄差异快照。您将需要在一个数据库实例（建议使用只读从属服务器）上编写完整的“具有读取锁定的锁定表”，并转储您的binlog位置或GTID，但是对于这些文件管理器，您将能够使用这些快照来创建数据库的新实例。您将需要将binlog放在单独的分区上，而仅将数据库数据放在这些分区上。完成后，您将能够克隆这些分区（在NetApps上，这称为“ FlexClone ”
这是因为对于每个读取的块，文件管理器都必须确定数据是驻留在冻结的原始快照中还是驻留在增量中。对于具有多个快照的卷/存储，可能需要多次检查。您可以通过刷新数据（意味着丢弃快照并定期对其进行克隆-对于良好的连续部署环境可能自然而自然地发生）来解决此问题，或者通过永久拆分卷（在NetApp术语中称为“ Flex Split”） ），这将需要一些时间来永久解决增量问题，并创建一个全新的独立卷。
这些增量克隆具有减少总体存储需求的额外好处-您可以产生多个克隆或生产数据库数据实例来进行开发，测试和验证。如果仅保留大型数据集的一个副本以及较小的增量（可能是小型增量），则可以降低总体存储成本和占地面积。
这里唯一的技巧是，由于“备份”仍驻留在文件管理器中，因此这可能无法构成完整的备份解决方案。为此，您可能需要使用NetApp称为Snap Mirror的东西，该文件将在文件管理器甚至数据中心之间镜像数据（使用rsync风格的技术），或者使用某种类型的集成备份解决方案，该解决方案可以将一个增量快照或一个快照备份到磁带上。弹性克隆。
但是，这有一个主要缺陷：您的所有数据-开发人员，测试人员和生产人员仍在同一文件管理器和存储头上使用I / O。要解决此问题，请考虑在第二个文件管理器上创建一个从数据库实例，这可以成为您测试和/或开发文件管理器的种子点，或者考虑为应用程序层使用负载平衡器/应用程序交付控制器将生产请求镜像到您的测试（和/或开发）环境。这样做还有一个好处，那就是在将产品流量投放到QA /测试环境之前，先针对可能不会立即注意到的问题进行生产，然后再推广到生产环境。然后，您可以根据生产流量和用户行为检查日志中是否存在错误。
然后，这应该允许您使用一些脚本以编程方式生成和销毁整个（大型）数据集，以用于连续部署方法。
可扩展性和高可用性
当您询问连续部署时，DevOps 不仅考虑了连续部署-因此，我将介绍一些有关冗余，可伸缩性和高可用性的信息。
我提到了JIT，即刻和最终的一致性。这就是各种RDBMS引擎的用武之地。只需配置循环异步复制，最终一致性就相对容易了。但是，这可能会导致一些冲突*（如果您的应用程序层在复制完成之前在集群的一侧和集群的另一侧更新数据，该怎么办？）要立即保持一致性，请查看将强制同步复制的Galera集群，但是导致可伸缩性问题（如何将其复制到灾难恢复站点或在地理位置上进行负载平衡，而又不会由于网络层的传播延迟而导致明显的延迟？）您还可以查看是否可以在数据中心内进行同步复制以及在站点之间进行异步复制，但这似乎是两全其美。
但是，通常，大多数人并不需要完全同步复制- 通常仅在非常特殊（且非常特殊）的高写入环境中需要这种复制，而表分片需要多主机。大多数应用程序可以使用数据库代理来处理即时一致性。例如，ScaleArc将监视复制状态并跟踪刚刚写入的位置（发送后续的读取请求，直到复制赶上），以提供及时的一致性和外观数据库一致性。ScaleArc与Postgres，MySQL，MariaDB，Oracle和MSSQL兼容，并且可以使用正则表达式对无法使用分片键的应用程序进行数据库分片/分区。它还具有强大的REST API，供您的配置管理软件与之交互-他们的支持团队非常出色
同样，您可能希望考虑由MariaDB团队为MariaDB开发的免费替代产品MaxScale。但是，它缺少GUI和ScaleArc的某些缓存功能。
最后，MySQL架构（如果可以承受那么多的RAM，则只有RAM中的MySQL群集）是其他潜力-尤其是MySQL的新代理。这可以为您的环境提供可伸缩性和冗余组件。
Postgres和Oracle应该具有所需的复制和分片功能，但如果需要代理，ScaleArc可以很好地配对。
最终，如果您不能简单地使用基于云的环境并让您的云提供商为您解决上述问题，那么所有这些因素加在一起便构成了一个高度适合连续部署和开发的环境。