データベースをシャード化する場合、ある1つのシャードに対する DDL 変更は、すべてのシャードで同時に有効になる必要があります。また、可能な限り複雑な操作は避けてください。DMS のスキーマ設計機能では、シャード化されたテーブルを単一の論理テーブルとして扱うため、個別のシャードを管理することなく、環境間でスキーマ変更を定義・昇格(プロモート)できます。本トピックでは、論理テーブルのスキーマ設計の使い方について説明します。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
以下のいずれかのタイプのデータベース:
MySQL:ApsaraDB RDS for MySQL、PolarDB for MySQL、ApsaraDB MyBase for MySQL、またはその他のソースからの MySQL データベース
OceanBase
セキュリティコラボレーション モードで管理されているインスタンス。詳細については、「インスタンスのコントロールモードを表示する」をご参照ください。
開発環境タイプの論理データベースをベースデータベース(設計フェーズ)として設定し、本番環境タイプの論理データベースを対象データベース(リリースフェーズ)として設定していること。詳細については、「論理データベース」および「インスタンスの環境タイプを変更する」をご参照ください。
ベースデータベースおよび対象データベースに対して変更を行う権限があること
ベースデータベースと対象データベースは、同じタイプである必要があります。たとえば、ベースデータベースが MySQL の場合、対象データベースも MySQL でなければなりません。
デフォルトでは、MySQL のセキュリティルールにより、設計フェーズの環境は開発環境、リリースフェーズの環境は本番環境に設定されます。R&D プロセスを要件に合わせて調整してください。詳細については、「スキーマ設計」をご参照ください。
スキーマ変更の設計と適用
スキーマ変更は、3段階の昇格(プロモート)フローに従います:ベースデータベース(開発)での設計 → ベースデータベースへの適用 → 対象データベース(本番)への昇格(プロモート)。各ステップではチケットの提出が必要であり、セキュリティルールに応じて承認も必要になります。
ステップ 1:スキーマ設計チケットの作成
DMS コンソール V5.0 にログインします。
上部ナビゲーションバーで、データベース開発 > スキーマ変更 > スキーマ設計 の順に選択します。
シンプルモードの場合、左上隅の
アイコンにポインターを合わせ、すべての機能 > データベース開発 > スキーマ変更 > スキーマ設計 の順に選択します。スキーマ設計チケット ページの右上角にある スキーマ設計 をクリックします。
以下のパラメーターを設定し、送信 をクリックします。
パラメーター 説明 ベースデータベースの変更 スキーマ設計用の論理データベースです。セキュリティコラボレーションモードで管理されているデータベースを選択してください。環境タイプは、データベースのセキュリティルールで定義された R&D 標準に準拠している必要があります。詳細については、「スキーマ設計」をご参照ください。 ステークホルダーの変更 チケットの詳細を閲覧し、開発および承認を支援できる関係者です。DMS 管理者およびデータベース管理者(DBA)は常にチケットの詳細を閲覧できます。その他のユーザーは、ここに追加された場合のみ閲覧可能です。
ステップ 2:論理テーブルのスキーマ定義
GUI または SQL ステートメントを使用して論理テーブルを定義します。
GUI を使用する
論理テーブルの作成 をクリックします。
基本情報、カラム情報、インデックス情報 タブを使用して、基本情報、カラム、インデックスを設定します。
パーティションテーブルのトポロジー をクリックし、論理テーブル式 フィールドにシャード式を入力します。式の完全な構文については、「論理テーブルの式」をご参照ください。
警告シャード式を変更すると、元のテーブルが削除され、新しいテーブルが作成されます。この操作は取り消せません。
テーブルトポロジーのディストリビューションを計算 をクリックして、シャード名とその物理データベースへの分散状況をプレビューします。プレビューには、各シャード名とマッピング先の物理データベースが表示されます。結果が期待通りでない場合は、式を調整して再計算してください。
保存 をクリックします。
SQL ステートメントを使用する
SQL ステートメントのインポート をクリックします。
CREATE TABLEまたはALTER TABLEステートメントを入力し、OK をクリックします。次の例では、範囲式を使用してorders_logic_[05]およびorders_logic_[06]の2つのテーブルを作成しています。CREATE TABLE `orders_logic_[05-06]` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'プライマリキー', `gmt_create` datetime NOT NULL COMMENT '作成時刻', `gmt_modified` datetime NOT NULL COMMENT '更新時刻', PRIMARY KEY (`id`) ) DEFAULT CHARACTER SET=utf8 COMMENT='論理テーブルの作成';論理テーブルの作成:orders_logic_[05-06] タブで、テーブル情報およびスキーマを確認し、保存 をクリックします。
既存テーブルのシャード式を変更しないでください。
ステップ 3:事前チェック結果の確認
保存後、DMS はテーブル作成、フィールド変更、インデックス変更に関する約40項目の R&D 標準に基づいて事前チェックを実行します。事前チェックが通過した場合にのみ、スキーマ変更は承認ステップに進みます。
| 結果 | 操作 |
|---|---|
| 通過 | 変更を確認して保存に送信 をクリックして続行します。 |
| 警告 | 警告を無視して保存を続行 をクリックして続行するか、閉じる をクリックして R&D 標準に従ってスキーマを修正し、再度 保存 をクリックします。 |
| エラー | 閉じる をクリックして R&D 標準に従って原因を特定・修正し、再度 保存 をクリックします。 |
事前チェックが通過すると、DMS は自動的に プロジェクトのホームページ タブに移動します。プロジェクトで変更されたテーブル タブで、承認に進む前にテーブルの確認・修正・削除を行ってください。
ステップ 4:ベースデータベースへの変更適用
ベースデータベースへの変更実行 をクリックします。
ベースデータベースへの変更実行 パネルで、実行戦略、カナリアモード、カナリア操作 を設定し、送信 をクリックします。
承認後、DMS は自動的にスキーマ変更をベースデータベースに適用します。変更実行履歴 タブで進行状況を追跡できます(各物理データベースごとにステータスが報告されます)。結果を確認するには、ベースデータベースの SQLConsole タブを開きます。
デフォルトでは、スキーマ変更にはチケットの提出が必須です。カスタムセキュリティルールも使用できます。たとえば、開発データベースにおけるスキーマ変更には承認不要とする指定や、本番データベースにおけるスキーマ変更チケットの承認権限を持つユーザーを指定することができます。
ステップ 5:本番データベースへの昇格(プロモート)
次のノードへ移動 をクリックし、ダイアログで確認します。
プロジェクトのホームページ タブで、対象データベースへの変更実行 をクリックします。
対象データベースへの変更実行 パネルで、宛先データベースを選択し、送信 をクリックします。
複数の本番データベースに一度にスキーマ変更を適用するには、複数のデータベースを追加 をクリックします。
承認後、DMS は自動的に変更を本番データベースに適用します。結果は、本番データベースの SQLConsole タブで確認できます。
次のノードへ移動 をクリックし、ダイアログで確認します。
チケットがクローズされた後、任意のステップをクリックして変更および公開記録を確認できます。
次のステップ
クエリを適切なシャードにルーティングするためのルーティングアルゴリズムを設定します。詳細については、「ルーティングアルゴリズムの設定」をご参照ください。