CRDB在线模式变化
#database #cockroachdb

在线模式更改问题到底是什么？

传统上更改桌子的架构是关系数据库中最具挑战性的问题之一每周。运行Alter Table或任何DDL语句都将使表处于无法访问的状态，包括读取。这是大多数应用程序无法简单地拥有的停机时间。这驱动了无停机时间在线模式解决方案的需求。

蟑螂的在线模式更改概述

Cockroachdb实际上是从地面上进行的，非常可用且适合所有OLTP需求，尽管我们有机会解决此在线模式变化问题，但我们同意我们希望提供一种更简单的方法来使用任何DDL语句，并确保该系统在此更改期间不会遭受任何负面后果。模式更改引擎是一项内置功能，不需要其他工具，资源或操作的临时测序。
例如，当您在CRDB的桌子上运行Alter时，背景作业将在后台启动，而CRDB引擎无缝地通过新更改来转换旧架构，而无需在基础表数据上锁定锁。



因此，基本上，您的应用程序的查询可以正常运行，而不会影响任何读取/写入延迟，并且在整个架构更改过程中，数据处于一致的状态，使您可以访问旧数据，直到新更改推出为止。
有关如何内部完成此操作的详细信息，您可以检查我们的
Official documentation

用CRDB专用云测试在线模式更改

现在，让我们看看蟑螂数据库如何处理现实中的在线模式变化。对于这里的练习，目标是在活动系统中对模式进行更改，并查看CRDB引擎是否可以优雅地处理更改而没有停机时间。

练习前进行锻炼

  • 在CRDB中创建了一个专用群集，并具有以下配置 crdb_cluster consoleOverview

  • 创建了一个新的用户管理模式，并使用一些关系表，例如用户，约会，位置等 我们使用我的合着者@jhatcher9999插入了数据：

  • 要模拟DB作为具有恒定读取/写入的活动系统，我们使用了CRDB的开源工具Workload tool- QueryBench（量身定制了此模式）。
    query-bench

DB-console-workload
在上面的数据库控制台中，您可以注意到QPS大约为10K，并且通过通过Workload工具（Query Bench）接受两个读取/写入系统。

完成预工作完成后，您可以使用众多方法之一连接到簇的SQL Shell来测试更改模式的不同方案。

Alter表添加新列
对于第一种情况，让我们在现有表的“用户”中添加列，并查看DB如何处理。

ALTER TABLE USERS ADD COLUMN user_marital_status CHAR(1) NULL;
  • 观察：执行alter的总时间约为120ms，一旦发布了Alter命令，在控制台的“ jobs”部分下创建了背景作业，您可以从此处监视此DDL语句的状态。

alter-column-sql

job-status

statement-time

Alter Table添加带有回填的新列
对于第二种情况，我们将列添加到带有回填的users表中。

ALTER TABLE USERS ADD COLUMN user_subscribed_status CHAR(1) NOT NULL DEFAULT 'y';
  • 观察：用户表具有6m记录，并在此表中添加带有回填的列，比以前的方案更长一点，我注意到该语句也创建了后台作业，我可以通过控制台。另外，正如您在下图中从DB控制台中看到的那样，在此更改中，对系统的主动读取/写入从未受到影响。
    • 。

job-status

job-stat1-sql

metric-job

更改表的主要键
对于这种情况，我们将测试系统在系统正在积极提取读取/写入请求时如何对更改表的主键做出反应。

ALTER TABLE appointments ALTER PRIMARY KEY USING COLUMNS (id, userid);
  • 观察：更改主要键几乎是瞬时和无缝的。总的执行时间低于120m。有一项背景工作负责封面下的变化，而这样做的过程中没有任何读取/写入受到影响。

pk-change-sql

metrics-pk

将新添加的列放在表中
这种情况仅仅是为了测试删除所有未使用的列形成表。在我们的情况下，我们想丢弃刚刚添加的两列，一个没有回填，另一个没有回填。

ALTER TABLE USERS DROP COLUMN user_marital_status;
ALTER TABLE USERS DROP COLUMN user_subscribed_status;
  • 观察：我们将这两个命令背对背运行，系统确实在后台创建了一项工作以监视该语句，并且在列出列时没有注意到任何错误，并且仍在提供了任何问题，而该列仍没有任何问题。 D B。

db-exec

console-db

恢复原始
的主要键 对于最终方案，我们只是恢复了主要键，以返回使用ID进行约会表。

ALTER TABLE appointments ALTER PRIMARY KEY USING COLUMNS (id);
  • 观察结果：运行Alter后，我立即注意到创建了用于处理更改的后台作业，并且SQL Shell在更改完成后返回。为此方案提供读取/写入也没有错误。

sql-pk

pk-revert

结论

总的来说，我们运行了上述方案，并且数据库对它们进行了异常很好的处理。我们没有遇到任何错误或从工作负载中的读取/写入的任何错误，因此系统在架构更改过程中连续处理请求。同样，可以对这些DDL语句在后台创建的作业进行监控和管理，以便您可以在旅途中暂停/恢复它们。
您可以参考以下屏幕截图，以获取及其执行时间的语句列表，并在执行过程中注意零SQL错误。因此，这就是CockrocreDB的在线模式变化问题的好处，整个DB王国从此过着幸福的生活。

Execution_all

erros-none

特别感谢我的朋友@jhatcher9999与我合作，与我合作，使这项练习更加有趣和令人兴奋。