数据库迁移
本指南提供有关数据库迁移的信息。
概念
迁移工具会为所有表创建 source_hash 和 target_hash 表,并存储其余列的主键和 MD5 散列算法。系统将针对所有行 (还包括源表和目标表的行) 计算散列值。
先决条件
支持的 Codebeamer 版本:
2.0.0.0 或更新版本的 SP
2.1.0.0 或更新版本的 SP
已安装 Docker 的 Linux 计算机。
Oracle 19.x 或 PostgreSQL 16.x 数据库。
源数据库必须仅适用于迁移工具。
必须在目标数据库中创建空架构。
未使用数据库功能构件。
源数据库和目标数据库中新源散列表的可用磁盘空间足够。建议将分配磁盘的一半留空。
* 
从 MySQL 8.30 开始,提供了 Generated Invisible Primary Keys 功能。
在启动迁移脚本之前,请确保 sql_generate_invisible_primary_keyOFF
* 
使用主机的 IP 地址,而非使用 (源和目标) 数据库主机的 Localhost。
* 
要在 Windows 中编辑 config.conf,请使用 Notepad。请不要使用富文本编辑器。
* 
如果可能,请避免在目标数据库密码中使用特殊字符。
* 
确保在 config.conf 的最后一行 (cb.minor.version=) 的值后输入 LF (换行) 字符 (按 Enter)。否则,Version 表的 Minor 字段将保持空白,因为 Codebeamer 无法启动。
限制
在源数据库迁移后,不会删除临时表。临时表以 _temp 结尾。
如何创建 PostgreSQL
创建数据库应使用以下配置:
LC_COLLATE='en_US.UTF-8' LC_CTYPE='en_US.UTF-8' ENCODING 'UTF8'
如何创建 Oracle
创建数据库应使用以下配置:
GRANT CREATE SESSION, CREATE TYPE, CREATE TABLE, CREATE CLUSTER, CREATE TRIGGER, CREATE OPERATOR, CREATE SEQUENCE, CREATE INDEXTYPE, CREATE PROCEDURE, CREATE VIEW
GRANT EXECUTE ON CTXSYS.CTX_DDL
GRANT EXECUTE ON DBMS_LOB
GRANT EXECUTE ON DBMS_CRYPTO
DBMS_CRYPTO 授予可在迁移后移除。
迁移阶段
前阶段 - 针对源数据库运行步骤
1. 针对 history_search_update, initial_version, locks, session_user_licenses, task_reference_tag, user_key, reference_search_history, task_field_value, field_value_search_history, project_activity_log, computed_field_lookup, object_access_permission, object_notification, object_reference, object_approval_history, object_reference_filter, task_field_status_specific 创建包含主键的时间表
2. 清理无效数据。
3. 生成源散列表。
4. 声明源散列表生成成功。
Java 迁移阶段
将数据从源数据库迁移到目标数据库。
后阶段 - 针对目标数据库运行步骤
1. 创建目标数据库。
2. 创建序列。
3. 创建表。
4. 创建源散列表。
5. 设置版本号。
6. 生成目标散列表。
7. 声明目标散列表。
8. 验证源散列表和目标散列表。
9. 删除源散列表和目标散列表。
10. 添加视图和过程。
11. 移除无效数据。
12. 添加索引。
13. 添加主键。
14. 添加约束和外键。
如何运行迁移工具
配置
使用以下模板创建配置文件。
config.conf
# Number of threads is used for running hash computation script. Use the number of CPUs of source database.
db.parallel.sql_job_number=4
# Number of threads is used for running PK creation script. Use the number of CPUs of source database.(max 11)
db.parallel.pk_job_number=2
db.source.database.type=<mysql|postgresql|oracle>
db.target.database.type=<postgresql|oracle>
db.source.host=<database host>
db.source.port=<database port>
db.source.username=<database username>
db.source.password=<database password>
db.source.database=<database name>
db.target.host=<database host>
db.target.port=<database port>
db.target.username=<database username>
db.target.password=<database password>
db.target.database=<database name>
# default is true
migrator.run.pre_stage=<true|false>
# default is true
migrator.run.java_stage=<true|false>
# default is true
migrator.run.post_stage=<true|false>
# Run hash computation and validation or not
migrator.verify_rows=<true|false>
# It depends on your memory of the migration server and database server
migrator.fetch_size=3000
# It depends on your memory of the migration server and database server
migrator.batch_size=3000
# Number of maximum threads is used for running migration script. Use the number of CPUs of your migration machine
migrator.worker.threads=12
# Number is threads is used for processing one table, smaller or same as the total.sections configuration
migrator.table.parallel=12
# Number of sections that table is cut of
migrator.total.sections=24
# Drop or keep the hash tables, it is helpful for investigating migration issues, by default it is true
migrator.drop_hash_tables=<true|false>
# See the related section below, by default it is false
migrator.drop_document_cache=<true|false>
# See the related section below, by default it is true
migrator.update_boolean_values=<true|false>
# See the related section below, by default it is true
migrator.remove_000_characters=<true|false>
# Major version of the source Codebeamer. To obtain the value to use for this configuration, execute the following database query: SELECT major FROM version;
cb.major.version=22.10
# Minor version of the source Codebeamer. To obtain the value to use for this configuration, execute the following database query: SELECT minor FROM version;
cb.minor.version=-SP7
如何下载 Migrator 工具
Docker 镜像
intland/database-migration-tool:22.04-1.2
intland/database-migration-tool:22.10-1.3
intland/database-migration-tool:2.0-1.2
intland/database-migration-tool:2.1-1.3
如何提取 Docker 镜像
docker login -u intlandsnapshot -p 89bc690e-bf19-4014-885b-7cd4c6355ca2
docker pull < docker image>
docker logout
如何启动迁移工具
docker run -v <path of config.conf>:/conf/config -v <path of directory>:/conf/logs -i /rootfs/run-migration.sh
数据库配置
PostgreSQL 调整
synchronous_commit = off
* 
此配置必须设置为 ON 才能供生产使用。
Oracle
nls_length_semantics = CHAR
* 
此配置也用于迁移和生产。
测试运行的执行时间
大约 200G 的数据库在 AWS 上运行。
详情:
源 RDS 为 db.m5.2xlarge (8 vCPU / 32G / 4000 IOPS) 服务器
目标 RDS 为 db.m5.2xlarge (8 vCPU / 32G / 8000 IOPS) 服务器
迁移服务器为 m5.2xlarge (8 vCPU / 32G / 2000 IOPS) 服务器
网速高达 10 Gbps
MySQL -> Oracle 的执行时间
带验证
使用 2 个线程添加主键 - 2 小时 30 分钟
使用 4 个线程生成源地址散列 - 1 小时 10 分钟
从源数据库迁移到目标数据库 - 5 小时 30 分钟
使用 4 个线程生成目标散列表 - 22 分钟
验证源散列表和目标散列表 - 8 分钟
使用 4 个线程暂时删除主键 - 1 小时
移除无效数据 - 7 分钟
使用 4 个线程创建索引 - 7 分钟
使用 4 个线程添加主键 - 2 分钟
不带验证
使用 2 个线程添加主键 - 2 小时 30 分钟
从源数据库迁移到目标数据库 - 1 小时 50 分钟
使用 4 个线程暂时删除主键 - 1 小时
移除无效数据 - 7 分钟
使用 4 个线程创建索引 - 7 分钟
使用 4 个线程添加主键 - 2 分钟
MySQL -> PostgreSQL 的执行时间
带验证
使用 2 个线程添加主键 - 2 小时 30 分钟
使用 4 个线程生成源地址散列 - 1 小时 10 分钟
从源数据库迁移到目标数据库 - 5 小时
使用 4 个线程暂时删除主键 - 1 分钟
使用 4 个线程生成目标散列表 - 10 分钟
验证源散列表和目标散列表 - 21 分钟
移除无效数据 - 14 分钟
使用 4 个线程创建索引 - 12 分钟
使用 4 个线程添加主键 - 2 分钟
不带验证
使用 2 个线程添加主键 - 2 小时 30 分钟
从源数据库迁移到目标数据库 - 1 小时 40 分钟
使用 4 个线程暂时删除主键 - 1 分钟
移除无效数据 - 14 分钟
使用 4 个线程创建索引 - 12 分钟
使用 4 个线程添加主键 - 2 分钟
建议
验证步骤的时间占迁移时间的一半,迁移速度得以加快。
包含验证步骤和确认步骤的干运行迁移:
migrator.verify_rows=true
migrator.drop_hash_tables=false
包含验证步骤和确认步骤的实际迁移:
migrator.verify_rows=true
migrator.drop_hash_tables=true
不包含验证步骤和确认步骤的实际迁移:
migrator.verify_rows=false
migrator.drop_hash_tables=false
移除 document_cache 数据
document_cachedocument_cache_datadocument_cache_data_blobs 包含用于更快地重新建立数据库索引的数据。这些表在迁移之前可以截断:
SET foreign_key_checks = 0;
TRUNCATE TABLE document_cache;
TRUNCATE TABLE document_cache_data;
TRUNCATE TABLE document_cache_data_blobs;
SET foreign_key_checks = 1;
数据不一致
如果 migrator_update_boolean_values 设置为 true,则会在 MySQL 中执行以下 SQL 脚本,以修复数据不一致:
UPDATE object_notification_temp SET only_members = 0 WHERE only_members IS NULL;
UPDATE object_notification_temp SET deleted = 0 WHERE deleted IS NULL;
UPDATE task_type SET service_desk = 0 WHERE service_desk IS NULL;
UPDATE task_type SET template = 0 WHERE template IS NULL;
如果 migrator.remove_000_characters 设置为 true,则会在 MySQL 中执行以下 SQL 脚本,以修复数据不一致:
UPDATE task_field_history SET new_value = replace(new_value, 0x00, "") WHERE new_value LIKE CONCAT("%", CHAR(0x00 using utf8), "%");
UPDATE task_field_history SET old_value = replace(old_value, 0x00, "") WHERE old_value LIKE CONCAT("%", CHAR(0x00 using utf8), "%");
UPDATE task_field_value SET field_value = replace(field_value, 0x00, "") WHERE field_value LIKE CONCAT("%", CHAR(0x00 using utf8), "%");
* 
需将源数据库中的 migrator.remove_000_characters 设置为 true,因为 0x00 字符在 PostgreSQL 和 Oracle 中无效。
这对您有帮助吗?