データベースの移行

管理者ガイド > Codebeamer のメンテナンス > PostgreSQL へのデータベース移行 > データベースの移行

データベースの移行

このガイドでは、データベースの移行について説明します。

概念

移行ツールでは、すべてのテーブルについて source_hash テーブルと target_hash テーブルが作成され、プライマリキーと残りのコラムの MD5 ハッシュが保存されます。ハッシュは、ソースとターゲット上のすべての行に対して計算されます。

必要条件

• サポートされている Codebeamer バージョン:

◦ 22.04 以上の SP

◦ 22.10-SP7 以上の SP

◦ 2.0.0.0 以上の SP

◦ 2.1.0.0 以上の SP

• Docker がインストールされている Linux マシン。

• Oracle 19.x または PostgreSQL 12.x データベース。

◦ ソースデータベースを移行ツールでのみ使用できるようにする必要があります。

◦ 空のスキーマをターゲットデータベースに作成する必要があります。

• Artifact in Database 機能が使用されていない。

• ソースデータベースとターゲットデータベース上に新しいソースハッシュテーブル用の十分な空きディスクがある。割当ディスクの半分は空にしておくことを推奨します。

MySQL 8.30 以降、生成された非表示プライマリキー機能を使用できます。

移行スクリプトを開始する前に、sql_generate_invisible_primary_key が OFF になっていることを確認してください。

DB のホスト (ソースとターゲットの両方) で、Localhost ではなくホストマシンの IP アドレスを使用します。

Windows で config.conf を編集するには、メモ帳を使用します。リッチテキストエディタは使用しないでください。

可能であれば、ターゲット DB パスワードに特殊文字を使用しないでください。

制限事項

ソースデータベースでは、移行後に一時テーブルは削除されません。一時テーブルの末尾は _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 用に PK を含む一時テーブルを作成します。

2. 無効なデータをクリーンアップします。

3. ソースハッシュを生成します。

4. ソースハッシュテーブルの生成に成功したことをアサートします。

Java 移行ステージ

ソースからターゲットにデータを移行します。

ポストステージ - ターゲットデータベースで実行するステップ

1. ターゲットデータベースを作成します。

2. シーケンスを作成します。

3. テーブルを作成します。

4. ソースハッシュテーブルを作成します。

5. バージョン番号を設定します。

6. ターゲットハッシュを生成します。

7. ターゲットハッシュをアサートします。

8. ソースハッシュとターゲットハッシュを検証します。

9. ソースおよびターゲットのハッシュテーブルを削除します。

10. ビューと手順を追加します。

11. 無効なデータを除去します。

12. インデックスを追加します。

13. PK を追加します。

14. 制約と FK を追加します。

移行ツールの実行方法

コンフィギュレーション

次のテンプレートを使用してコンフィギュレーションファイルを作成します。

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>
# Version of the source codebeamer
cb.major.version=22.10
# Version of the source codebeamer
cb.minor.version=-SP7

移行ツールのダウンロード方法

Docker イメージ

• intland/database-migration-tool:22.04-1.2

• intland/database-migration-tool:22.10-1.2

• intland/database-migration-tool:2.0-1.2

• intland/database-migration-tool:2.1-1.2

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

詳細については、https://www.postgresql.org/docs/current/wal-async-commit.html#:~:text=Asynchronous%20commit%20is%20an%20option,is%20an%20acceptable%20trade%2Doff を参照してください。

本番環境で使用する場合、このコンフィギュレーションは ON に設定する必要があります。

Oracle

nls_length_semantics = CHAR

このコンフィギュレーションは、移行と本番環境での使用にも必要です。

テストランの実行時間

AWS 上で実行される最大 200G のデータベースを使用しました。

詳細:

• ソース 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 つのスレッドを使用して PK を追加 - 2 時間 30 分

• 4 つのスレッドを使用したソースハッシュ生成 - 1 時間 10 分

• ソースからターゲットに移行 - 5 時間 30 分

• 4 つのスレッドを使用してターゲットハッシュを生成 - 22 分

• ソースとターゲットのハッシュを検証 - 8 分

• 4 つのスレッドを使用して一時的に PK をドロップ - 1 時間

• 無効なデータを除去 - 7 分

• 4 つのスレッドを使用してインデックスを作成 - 7 分

• 4 つのスレッドを使用して PK を追加 - 2 分

検証なし

• 2 つのスレッドを使用して一時的に PK を追加 - 2 時間 30 分

• ソースからターゲットに移行 - 1 時間 50 分

• 4 つのスレッドを使用して一時的に PK をドロップ - 1 時間

• 無効なデータを除去 - 7 分

• 4 つのスレッドを使用してインデックスを作成 - 7 分

• 4 つのスレッドを使用して PK を追加 - 2 分

MySQL -> PostgreSQL の実行時間

検証あり

• 2 つのスレッドを使用して一時的に PK を追加 - 2 時間 30 分

• 4 つのスレッドを使用したソースハッシュ生成 - 1 時間 10 分

• ソースからターゲットに移行 - 5 時間

• 4 つのスレッドを使用して一時的に PK をドロップ - 1 分

• 4 つのスレッドを使用してターゲットハッシュを生成 - 10 分

• ソースとターゲットのハッシュを検証 - 21 分

• 無効なデータを除去 - 14 分

• 4 つのスレッドを使用してインデックスを作成 - 12 分

• 4 つのスレッドを使用して PK を追加 - 2 分

検証なし

• 2 つのスレッドを使用して一時的に PK を追加 - 2 時間 30 分

• ソースからターゲットに移行 - 1 時間 40 分

• 4 つのスレッドを使用して一時的に PK をドロップ - 1 分

• 無効なデータを除去 - 14 分

• 4 つのスレッドを使用してインデックスを作成 - 12 分

• 4 つのスレッドを使用して PK を追加 - 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_cache、document_cache_data、および document_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), "%");

以下も参照してください。

• PostgreSQL データベースの準備

• Oracle を使用した Codebeamer データベースのインポートとエクスポート

これは役に立ちましたか?