哪些实践或工具可以实现数据库的连续部署？

#1 楼

Pramod Sadalage和Scott Ambler写了一本书《重构数据库：进化数据库设计》，这是CD组织/团队中DB主题的坚实基础。

#2 楼

挑战



我知道有些做法，例如仅添加数据库对象（即表和列），而不修改或删除它们


在我工作过的一家公司中，原始数据的滚动窗口相当于大约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 Cluster？Spider？）和历史或兼容性要求（我们使用PL / SQL多年，我们一半的代码已内置在oracle引擎中！我们怎么能移植到MariaDB？！？） />
所有这些（显着）即时消息请为您提供可用的工具。其他SE用户也应该提出其他建议。

出于对通用考虑的考虑，让我为您提供一些解决上述问题的技术。首先，问问自己是否真的需要使用RDBMS，或者是否可以选择使用诸如Hadoop，CouchDB甚至面向对象存储（如swift）之类的非结构化数据。

其次，考虑研究基于云的解决方案。这将一些令人头疼的事情外包了，并将复杂的问题留给了高素质（和有偿）的个人。但是，从规模上看，您会发现这确实消耗了您的预算（云提供商确实从中获利，并且在一定规模上，您只能自己聘请这些专家，），或者如果您在特定的安全或政治环境下工作需求（阅读：我们不能做云）考虑混合NFS / FibreChannel Filer。这些文件管理器中的大多数文件管理器（例如NetApp，Pure Storage和Tegile的文件管理器）都支持基于增量的快照和克隆技术，对于A）进行备份，B）还原备份和C）播种新备份非常有用。

至此，我需要指出的是，我不是备份和存储专家，因此，在继续研究其他问题（和更绿色的牧场）之前，有一些我从未能够解决的问题。

但是，这些产品使您可以在数据库下方拍摄差异快照。您将需要在一个数据库实例（建议使用只读从属服务器）上编写完整的“具有读锁定的锁定表”，并转储您的binlog位置或GTID，但是对于这些文件管理器，您就可以使用这些快照来创建数据库的新实例。您将希望将二进制日志放在单独的分区上，而仅将数据库数据放在这些分区上。完成后，您将能够克隆这些分区（在NetApps上，这被称为“ FlexClone”），唯一的问题是它们无法跨越数据存储，这意味着您的所有I / O仍在影响同一数据存储/ volume和计算增量可能会导致一些CPU资源开销。

这是因为对于每个读取的块，文件管理器必须确定数据是驻留在冻结的原始快照中还是驻留在增量中。对于具有多个快照的卷/存储，可能需要多次检查。您可以通过刷新数据（意味着丢弃快照并定期对其进行克隆-对于良好的连续部署环境可能自然而自然地发生）来解决此问题，或者通过永久拆分卷（在NetApp术语中称为“ Flex Split”） ），这将需要一些时间来永久解析增量，并创建一个全新的独立卷。

这些增量克隆具有减少总体存储需求的额外好处-您可以生成多个克隆或实例。您的生产数据库数据来进行开发，测试和验证。如果您只保留一个大型数据集的副本以及（可能是）小的增量，则可以降低总体存储成本和占用空间。

这里的唯一技巧是，这可能不构成完整的备份解决方案，因为“备份”仍驻留在您的文件管理器上。为此，您可能需要使用NetApp称为Snap Mirror的东西，该文件将在文件管理器甚至数据中心之间镜像数据（使用rsync风格的技术），或者使用某种类型的集成备份解决方案，该解决方案可以将一个增量快照或一个快照复制到磁带上。 flex-clone。

但是，这有一个主要缺陷：您的所有数据-开发，测试和生产仍然在同一文件管理器和存储头上使用I / O。要解决此问题，请考虑在第二个文件管理器上创建一个从数据库实例，这可以成为您测试和/或开发文件管理器的种子点，或者考虑为应用程序层使用负载平衡器/应用程序交付控制器将生产请求镜像到您的测试（和/或开发）环境。这样做还有一个好处，那就是在升级到生产之前就可能无法立即注意到的问题，在QA / Test环境中投入产品流量。然后，您可以根据生产流量和用户行为检查日志中是否有错误。

然后，您应该可以使用一些脚本以编程方式生成和销毁整个（和大型）数据集，以进行连续部署方法论。


可伸缩性和高可用性

当您问及连续部署时，DevOps不仅考虑了连续部署-因此，我将介绍一些内容有关冗余，可伸缩性和高可用性的内容。

我提到了JIT，即刻和最终的一致性。这就是各种RDBMS引擎的用武之地。只需简单地配置循环异步复制，最终的一致性就相对容易了。但是，这可能会导致一些冲突*（如果您的应用程序层在复制完成之前在集群的一侧和集群的另一侧更新数据，该怎么办？）为了立即保持一致性，请查看Galera集群，它将强制进行同步复制，但是导致可伸缩性问题（如何将其复制到灾难恢复站点或在地理上进行负载平衡，而又不会由于网络层的传播延迟而导致明显的延迟？）您还可以查看是否可以在数据中心内进行同步复制以及站点之间进行异步复制，但这似乎是两全其美。

但是，通常，大多数人并不需要完全同步复制-通常仅在非常特殊（且非常特殊）的高写入环境中需要这种复制，而表分片需要多主机。大多数应用程序可以使用数据库代理来处理即时一致性。例如，ScaleArc将监视复制状态并跟踪刚刚写入的位置（发送后续的读取请求，直到复制赶上），以提供即时一致性和数据库一致性外观。 ScaleArc与Postgres，MySQL，MariaDB，Oracle和MSSQL兼容，并且可以使用正则表达式对无法使用分片键的应用程序对数据库进行分片/分区。它还具有健壮的REST API，供您的配置管理软件与之交互-他们的支持团队非常出色。

类似地，您可能希望考虑由MariaDB团队为MariaDB开发的免费替代产品MaxScale。它缺少GUI和ScaleArc的某些缓存功能。

最后，MySQL架构（以及RAM内唯一的MySQL群集-如果您能负担得起那么多的内存）还有其他潜力-特别是在MySQL的新代理。这可以为您的环境提供可伸缩性和冗余组件。

Postgres和Oracle应该具有所需的复制和分片功能，但是ScaleArc在需要代理的情况下可以很好地配对。

最终，如果您不能简单地使用基于云的环境，并让您的云提供商为您解决上述问题，那么所有这些因素加起来就构成了适合连续部署和开发的高度灵活的环境。

#3 楼

我们在工作中使用Flyway来管理应用程序中的Postgres架构，并使用Pillar来管理Cassandra架构。我们发现，如果应用程序管理其自己的架构是最好的。

在应用程序管理自己的模式之前，我们曾经历过糟糕的管理模式的经历。

#4 楼

我认为，除非您将架构责任转移给应用程序团队，否则仅靠工具是没有帮助的。 。

除此之外，您还可以避免纯粹的累加方式。
每个应用程序都必须与其先前的版本兼容，当必须更改架构时，该应用程序将在架构中集成一个新列，对其进行写入，并且仍在前一列中进行读写（允许前一版本仍然具有相同的数据）。
该应用程序的下一个版本允许停止更新

很明显，需要定期备份以防万一出现问题。
可能会创建适当的数据子集在集成测试中避免出现问题也是一个好主意。理想情况是获取生产数据的匿名子集。

#5 楼

我们在工作中使用liquibase，为此我会高度评价。我们的质量检查工具QASymphony也使用了它。

#6 楼

要在大型机环境的上下文中并且特定于DB2®数据库来回答这个问题，通常有两种常用的（不便宜的...）替代方法可供选择：


对象BMC的DB2®管理。以下是有关它的一些详细信息（在链接页面中引用）：

对数据库中的对象进行更改（甚至仅执行常规管理任务）可能是困难且冒险的工作。有许多任务需要跟踪，一个失误可能会对可用性和数据完整性造成灾难性的影响。您可以使用BMC Object Administration for DB2 11减少工作量和风险，该工具集可帮助您：

减少管理复杂且分散的DB2环境所需的时间。
自动化在整个应用程序生命周期中执行例行任务以提高完整性。
通过简化的DB2目录导航和变更管理来提高生产率。
通过以最小的中断执行变更和维护来提高应用程序可用性。




IBM的z / OS DB2管理工具。

它简化了与在整个应用程序生命周期中安全地管理DB2对象和模式相关的复杂任务，并且最少。可能对可用性产生影响。

使用户可以快速轻松地导航DB2目录
无需知道确切的SQL语法即可构建和执行动态SQL语句
管理和跟踪对DB2所做的更改解决对象定义的任何潜在冲突o执行
帮助构建针对数据库和表执行的DB2命令
使用户能够创建，更改，迁移，删除和反向工程DB2对象
构建和执行实用程序作业，从而使用户能够利用LISTDEF和模板以提高生产率




与SCM工具集成
不久前，我受到客户的挑战，要在他们的SCM生命周期（由SERENA ChangeMan ZMF管理）中实际“集成” BMC替代品。这种集成背后的想法是“将我们的DB2 DBA团队（使用DDL进行处理）作为开发团队的特例，不小心使用某些奇异的编辑器（BMC工具）来生成要迁移的代码（DDL）”。
关于此集成的唯一（但真正的！）挑战是还必须促进“可重新启动性”，这是此类DBA工具的主要优点之一：


可重新启动性意味着当此DBA工具执行其工作时（根据需要完成的工作的性质，有时需要长时间运行的工作），可能会发生意外的事情（死锁，时间浪费等）。


如果发生任何这些事情，并且您不想从备份中重新启动（在开始之前），那么DBA工具希望您从出现问题的（检查）点重新启动（以及您希望从那里重新执行所有操作的地方。）


更好（或者说“甚至更糟”？），如果不是真正的DBA工具知道如何重新从此类检查点开始，然后再次尝试（从头开始），则DBA工具将因某种用户错误而失败。并带有这样的指示：“直到您告诉我要我在最后一次失败之后如何继续工作，我才会拒绝做任何事情（以免使情况变得更糟）”。


最后，要在正在使用的SCM工具中实现这种可重新启动性的真正线索，还需要对SCM工具进行调整。实际上是允许它用于重新启动失败的SCM过程（通常与向目标测试/产品环境的交付有关）...而不仅仅是重新提交失败的SCM过程（这是那些SCM工具通常从这种情况下恢复的方式） ）。


奖励：BMC替代品的SCM集成完成后，客户决定将其DBA工具更改为IBM替代品。即使这两种选择看起来并不完全相同，但它对SCM集成的影响却很小：仅需替换（在某些可重用的SCM定制中）将BMC替代的某些调用替换为对IBM的等效调用替代方案...（使用DevOps术语）由功能标志/功能切换实现。