Delicate数据库迁移：无缝升级和版本迁移的完整操作手册

Delicate数据库迁移：无缝升级和版本迁移的完整操作手册

【免费下载链接】delicateA lightweight and distributed task scheduling platform written in rust. （一个轻量的分布式的任务调度平台通过rust编写）项目地址: https://gitcode.com/gh_mirrors/de/delicate

Delicate作为轻量的分布式任务调度平台，采用Rust编写，其数据库迁移系统确保了系统升级过程中数据结构的平滑过渡。本文将详细介绍Delicate的数据库迁移机制，帮助开发者和运维人员轻松应对版本升级带来的数据库变更。

数据库迁移核心组件

Delicate的数据库迁移功能主要由delicate-scheduler模块实现，通过Diesel ORM框架提供的迁移工具实现版本化管理。项目中迁移相关的核心文件结构如下：

delicate-scheduler/ ├── migrations/ │ ├── mysql/ # MySQL数据库迁移脚本 │ └── postgres/ # PostgreSQL数据库迁移脚本 └── src/db/mod.rs # 迁移执行入口

在Cargo.toml中可以看到迁移相关的依赖配置：

[dependencies] diesel_migrations = "^1.4.0" diesel = { version = "^1.4.6", features = ["postgres", "mysql", "extras", "r2d2", "chrono"] }

迁移脚本的组织方式

Delicate采用时间戳命名的迁移脚本文件，每个迁移包含up.sql（升级脚本）和down.sql（回滚脚本）。例如MySQL的初始迁移脚本位于：

delicate-scheduler/migrations/mysql/2021-04-15-123323_init/up.sql

这个脚本创建了系统运行所需的基础表结构，包括任务表、执行器表、用户表等核心实体。后续的功能增强会通过新的迁移脚本实现，如2021-07-27的富日志功能迁移：

delicate-scheduler/migrations/mysql/2021-07-27-110601_rich_logs/up.sql

图1：Delicate任务列表界面，数据库迁移确保这些任务数据在版本升级时不会丢失

自动迁移执行流程

Delicate在启动时会自动执行未应用的迁移脚本，核心代码位于delicate-scheduler/src/db/mod.rs：

pub(crate) fn init() { let connection = establish_connection(); // 执行必要的迁移 embedded_migrations::run(&connection).expect("Migration execution failed, please check the database account permission and database service availability."); init_admin_account(); }

系统会根据数据库类型（MySQL或PostgreSQL）嵌入相应的迁移脚本：

cfg_mysql_support!( embed_migrations!("./migrations/mysql"); ); cfg_postgres_support!( embed_migrations!("./migrations/postgres"); );

手动执行迁移的方法

虽然Delicate默认在启动时自动执行迁移，但在某些情况下可能需要手动触发：

1. 首先克隆项目仓库：

   git clone https://gitcode.com/gh_mirrors/de/delicate cd delicate

2. 使用Diesel CLI工具手动执行迁移：

   # 对于MySQL diesel migration run --database-url mysql://user:password@localhost/delicate --migration-dir delicate-scheduler/migrations/mysql # 对于PostgreSQL diesel migration run --database-url postgres://user:password@localhost/delicate --migration-dir delicate-scheduler/migrations/postgres

图2：执行器管理界面，数据库迁移确保执行器配置数据的兼容性

迁移脚本示例解析

初始迁移脚本创建了系统的核心表结构，以任务表task为例：

CREATE TABLE `task` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'Self-incrementing id', `name` varchar(128) NOT NULL COMMENT 'Task name', `description` varchar(128) NOT NULL COMMENT 'Task description', `command` varchar(256) NOT NULL COMMENT 'Task execute command', `frequency` varchar(256) NOT NULL COMMENT 'Task frequency', `cron_expression` varchar(256) NOT NULL COMMENT 'Task cron expression', `timeout` smallint(9) NOT NULL DEFAULT '0' COMMENT 'Task Timeout', `retry_times` smallint(6) NOT NULL DEFAULT '0' COMMENT 'Task retry times', `retry_interval` smallint(6) NOT NULL DEFAULT '0' COMMENT 'Task retest interval', `maximum_parallel_runnable_num` smallint(11) NOT NULL DEFAULT '0' COMMENT 'Maximum number of parallel tasks', `tag` varchar(32) NOT NULL DEFAULT '' COMMENT 'Task tag', `status` smallint(6) NOT NULL DEFAULT '1' COMMENT 'Task status', `created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Task creation time', `deleted_time` timestamp NULL DEFAULT NULL COMMENT 'Task deletion time', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

后续的迁移脚本通常会添加新表或修改现有表结构，如富日志功能迁移中添加了操作日志表：

CREATE TABLE operation_log ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Self-incrementing id', `name` varchar(64) NOT NULL DEFAULT '' COMMENT 'Operation module name', `table_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT 'Operation table id', `operation_type` tinyint(4) NOT NULL DEFAULT '1' COMMENT 'Operation type: 1 add 2 modify 3 delete', `user_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT 'Operation user id', `user_name` varchar(64) NOT NULL DEFAULT '' COMMENT 'Operation user name', `operation_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Operation time', PRIMARY KEY (`id`), KEY `idx_table_id` (`table_id`) USING BTREE, KEY `idx_operation_time` (`operation_time`) USING BTREE, KEY `idx_user_id_type_time` (`user_id`,`operation_type`,`operation_time`) USING BTREE )ENGINE INNODB DEFAULT CHARSET=utf8mb4 COMMENT 'User Operation Log Record Table';

迁移注意事项与最佳实践

1. 备份数据：在执行迁移前，建议备份数据库，特别是生产环境

2. 测试环境验证：新的迁移脚本应先在测试环境验证，确保不会影响现有功能

3. 监控迁移过程：迁移过程中注意观察日志输出，如出现错误可通过以下方式排查：

   # 查看应用启动日志，包含迁移相关信息 tail -f delicate-scheduler/logs/app.log

4. 版本控制：迁移脚本应纳入版本控制，与代码版本保持同步

图3：任务日志详情界面，数据库迁移确保历史日志数据的可访问性

回滚迁移的方法

如果迁移后发现问题，可以通过回滚脚本恢复到之前的状态：

# 回滚到上一个版本 diesel migration revert --database-url mysql://user:password@localhost/delicate --migration-dir delicate-scheduler/migrations/mysql

每个迁移的回滚脚本位于对应的down.sql文件中，例如：

delicate-scheduler/migrations/mysql/2021-07-27-110601_rich_logs/down.sql

总结

Delicate的数据库迁移系统基于Diesel ORM实现，通过时间戳命名的迁移脚本和自动执行机制，确保了系统升级过程中数据结构的兼容性和数据的安全性。无论是开发环境还是生产环境，遵循本文介绍的迁移流程和最佳实践，都能实现Delicate的无缝升级和版本迁移。

官方文档中关于数据库迁移的更多细节，请参考项目中的迁移脚本目录：delicate-scheduler/migrations/。通过合理使用这些工具和脚本，开发者可以专注于功能开发，而不必担心数据库版本管理的复杂性。

【免费下载链接】delicateA lightweight and distributed task scheduling platform written in rust. （一个轻量的分布式的任务调度平台通过rust编写）项目地址: https://gitcode.com/gh_mirrors/de/delicate