对 Amazon Aurora 进行数据库变更管理

这是一个关于 Amazon Aurora 数据库变更管理的系列文章。 * Amazon Aurora 数据库变更管理（这一篇） * Amazon Aurora 和 GitHub 联动进行数据库变更管理 *** [Amazon Aurora](https://aws.amazon.com/rds/aurora/) 是一个与 MySQL 和 PostgreSQL 兼容的关系数据库，它为云计算而构建，将传统企业数据库的性能和可用性与开源数据库的简单性和成本效益结合在一起。 本教程是在 Bytebase 中为 Amazon Aurora MySQL 设置数据库变更管理的分步指南。通过 Bytebase，团队可以有一个正式的审核和发布过程来进行 Amazon Aurora 数据库 schema 变更和数据变更。 Bytebase 为团队提供了一个图形化界面来执行数据库变更并保留完整的变更历史。你可以使用 Bytebase 免费版来完成本教程。 在最后，有一个关于 schema 漂移检测的彩蛋章节，供那些高级用户使用。 ## 功能包括 - 变更工作流程 - Schema 编辑器 - SQL 编辑器 - 变更历史 - DML 回滚 - 漂移检测 ## 准备工作 在你开始之前，请确保你： - 有一个 Amazon Aurora MySQL 实例。 - 安装了 [Docker](https://www.docker.com/)。 ## 第一步 - 通过 Docker 部署 Bytebase 1. 确保 Docker 正在运行，并输入以下命令启动 Bytebase Docker 容器。 ``` docker run --init \ --name bytebase \ --platform linux/amd64 \ --restart always \ --publish 5678:8080 \ --health-cmd "curl --fail http://localhost:5678/healthz || exit 1" \ --health-interval 5m \ --health-timeout 60s \ --volume ~/.bytebase/data:/var/opt/bytebase \ bytebase/bytebase:1.14.0 \ --data /var/opt/bytebase \ --port 8080 ``` 2. Bytebase 在 Docker 中运行，你可以通过`localhost:5678` 访问它。  3. 在浏览器中访问 `localhost:5678`。注册第一个管理员账户，该账户将被授予 [`工作区所有者`] (https://www.bytebase.com/docs/concepts/roles-and-permissions) 角色。  ## 第二步 - 在 Bytebase 中添加一个 Amazon Aurora MySQL 实例 在 Bytebase 中，实例可以是你的内部 MySQL 实例，也可以是 AWS RDS 实例等，在本教程中，**实例**是你的 "Amazon Aurora MySQL 实例"。 1. 访问 `localhost:5678` 并作为 `工作区所有者` 登录。  2. 点击**添加实例**。  3. 填写字段并点击**创建**。请注意这些字段。 - **类型**。`MySQL`，如果你使用 Aurora PostgreSQL，选择 `PostgreSQL` 代替。 - **环境**：选择`测试'，如果你选择`开发'，你将需要手动批准所有未来的更改请求，默认情况下，让我们在本教程中保持简单。  ## 第三步 - 创建一个项目 在 Bytebase 中，项目将逻辑上相关的数据库、工单和用户组合在一起，这与其他开发工具（如 Jira 和 GitLab）中的项目概念相似。所以在你处理数据库之前，必须先创建一个项目。 1. 点击顶部导航栏上的项目。 2. 点击 **创建项目**，创建一个新的项目 TestAurora，键为 TAR，模式为 标准。点击 **创建**。  ## 第四步 - 通过 Bytebase 创建一个 Amazon Aurora MySQL 数据库 在 Bytebase 中，一个数据库是由 “CREATE DATABASE xxx” 创建的。一个数据库总是属于一个单一的项目。一个工单代表了开发人员和 DBA 之间在创建数据库、变更 schema 时的特定合作活动。它类似于其他问题管理工具中的工单的概念。 1. 点击左侧边栏上的 项目 > TestAurora。点击**创建数据库**，创建一个新的数据库。你也通过点击**转移数据库**来转入你现有的数据库。 2. 在表格中填写名称 - db_demo, 环境 - Test, 和实例 - Amazon Aurora MySQL。点击**创建**。 3. Bytebase 将创建一个工单来自动创建数据库。由于是测试环境，该工单将默认自动执行而不需要等待你的批准。点击**解决**，这个问题就完成了。  ## 第五步 - 在 Amazon Aurora MySQL 中创建一个表 在第四步中，你创建了一个工单，使用 UI 工作流创建一个数据库，然后执行了它。让我们继续创建一个表。 1. 访问你的项目，并点击**变更 schema**。 2. 选择 `db_demo` 并点击下一步。  3. 这就是你可以尝试使用 **Schema 编辑器**的地方。这是一个用于变更 Schema的可视化编辑器。创建一个名为 `t1` 的表，有两列：`id` 和 `name`。  4. 点击**预览工单**，Bytebase 会自动预览一个带有相应 SQL 语句的工单。确认它是正确的，然后点击**创建**。  5. 由于该问题是针对测试环境的，所以默认情况下会自动批准。同时，Bytebase 在执行 SQL 之前已经运行了几个任务检查，其中一个任务检查被称为 SQL Reivew。你可以[定制你自己的SQL审查策略](https://www.bytebase.com/docs/sql-review/review-policy/overview)。 6. 点击**解决**，该工单将变成`完成`。  7. 在工单页面，点击**查看变化**，你可以看到 schema 差异。  ## 第六步 - 通过SQL编辑器添加一些数据和查询 1. 转到项目 `TestAurora`，并点击**改变数据**。 2. 选择 `db_demo` 并点击**下一步**。 3. 按以下方式填写 SQL，然后点击**创建**。 ```sql INSERT INTO t1 VALUES (1, 'Adela'); ``` 4. 在其执行后，单击**解决**。  5. 点击左侧栏的**SQL编辑器**。输入查询并点击**运行**。你可以看到新的记录在那里。  ## 第七步 - 回滚数据变更 Bytebase支持[MySQL的回滚](https://www.bytebase.com/docs/change-database/rollback-data-changes)。 在数据变更完成后，Bytebase 可以解析 MySQL 二进制日志并从日志中建立回滚 SQL 语句。这允许你在需要时恢复该数据变化。 1. 回到工单中，将SQL回滚打开。  2. 如果实例没有设置`binlog_format = ROW`，它可能会失败。  3. 进入 Amazon RDS，点击**参数组**，创建一个新的参数组，将`binlog_format`设置为`ROW`。   4. 把这个参数组应用到你的数据库实例。  5. 回到 Bytebase SQL 编辑器，并切换到管理模式。  6. 根据[亚马逊文档](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-stored-proc-configuring.html#mysql_rds_show_configuration)。输入以下内容，将 binlog 的保留时间设置为24小时。 ``` call mysql.rds_set_configuration('binlog retention hours', 24); ``` 7. 键入以下内容以检查它是否设置成功。 ``` CALL mysql.rds_show_configuration; ```  8. 重新启动Aurora MySQL实例。 9. 重复步骤六，但这一次，我们可以看到**预览回滚工单**。点击它，然后在问题页面上点击**创建**。   10. 回滚总是需要明确的批准。  11. 在批准回滚之前，让我们去 SQL编辑器并且查询。Bella这条数据已经插入。  12. 回到工单页面，点击**批准**。回滚的SQL 将执行。  13. 进入 SQL 编辑器，再次查询。Bella这条记录已经不在那里了 - 回滚成功。你也可以回滚，是的，回滚是为了回滚...... 只要 binlog 是在 24 小时的保留期内。  ## 彩蛋部分 - Schema 漂移检测 要使用这个功能，你需要激活企业版的 Bytebase（你可以直接开始14天的试用，不需要信用卡）。 现在你可以看到数据库 `db_demo` 的全部变化历史。然而，什么是**建立新的基线**？什么时候使用它？ 通过采用 Bytebase，我们希望团队在所有的 Schema 变更中只使用 Bytebase。同时，如果有人在 Bytebase 之外做了 Amazon Aurora schema 的改变，显然 Bytebase 不会知道。因为 Bytebase 已经记录了它自己的 schema 副本，当 Bytebase 将有由外部变化的实时模式进行比较时，它将注意到一个差异，并显示一个 schema 漂移的异常情况。如果该变化是有意的，那么你应该建立新的基线来再次协调 schema 的状态。 在本节中，我们将指导你完成这个过程。 1. 你可以使用一个外部GUI或者终端来对db_demo进行修改。在本教程中，我们使用Bytebase SQL 编辑器的**管理模式**，当我们说在 Bytebase 之外进行更改时，这种管理模式也算。进入 SQL 编辑器，并切换到管理模式。 当你在管理模式下进行更改时，它不会像正常模式那样记录任何历史记录 www.bytebase.com/docs/sql-editor/admin-mode  2. 粘贴以下内容，然后按回车键： ```sql ALTER TABLE t1 ADD COLUMN age integer； ``` 3. 粘贴以下内容，然后按回车键来验证它的存在： ``` SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_name = 't1'; ```  4. 等待 10 分钟（因为 Bytebase 大约每 10 分钟做一次检查）。到异常中心，你可以找到 schema 漂移的情况。  5. 点击**查看差异**，你会看到确切的漂移。  6. 你也可以通过点击数据库 > `db_demo` 找到漂移。  7. 进入数据库 > db_demo > 变更历史，然后点击建立新的基线，这一步建立一个新的基线，从实时数据库模式中调和 schema 状态。  8. Bytebase 将创建一个问题来建立新的基线，点击**创建**，然后**解决**来标记它完成。 9. 回到数据库 > db_demo或异常中心，你会发现漂移已经消失。 ## 总结和接下来 现在你已经把 Amazon Aurora 和 Bytebase 连接起来了，并且使用 UI 工作流来完成 schema 变更和数据变更。Bytebase 将为你记录完整的变更历史。此外，企业版本配备了 schema 漂移检测，以检测在 Bytebase 之外执行的 schema 变更。 在下一篇文章中，你将尝试 GitOps 工作流程：将你的 Amazon Aurora schema存储在 GitHub 中，Bytebase 将接收对 repo 的更改，将你的 Amazon Aurora 变更工作流程提升到新的水平，也就是数据库 DevOps - 数据库即代码。