ApsaraDB RDS for SQL Server は、クラウドへの増分データ移行を可能にします。まず、完全バックアップファイルを Alibaba Cloud Object Storage Service (OSS) にアップロードし、次に ApsaraDB RDS コンソールを使用して指定された ApsaraDB RDS for SQL Server インスタンスにデータを復元します。最後に、差分バックアップファイルまたはログバックアップファイルをインスタンスにインポートして移行を完了します。このプロセスにより、ダウンタイムを数分に短縮できます。
ユースケース
RDS SQL Server への増分データ移行は、次のユースケースで使用します:
-
論理移行ではなく、バックアップファイルを使用して RDS SQL Server への物理移行を実行したい場合。
説明-
物理移行はファイルベースですが、論理移行はデータから DML ステートメントを生成し、移行先の RDS SQL Server インスタンスで実行します。
-
物理移行では、移行先データベースがソースデータベースと 100% 同一であることが保証されます。一方、論理移行ではこの一貫性を保証できません。たとえば、インデックスの断片化や統計情報などの属性が移行後に異なる場合があります。
-
-
ダウンタイムを数分に抑える必要がある場合。
説明より長いダウンタイム (たとえば 2 時間の停止) が許容でき、データベースが 100 GB 未満の場合は、完全バックアップファイルを使用してデータベースを移行してください。
前提条件
-
ご利用の RDS for SQL Server インスタンスは、次の要件を満たす必要があります:
-
インスタンスは SQL Server 2012 以降を実行しているか、クラウドディスクを使用する SQL Server 2008 R2 インスタンスである必要があります。
-
インスタンスに、移行しようとしているデータベースと同じ名前のデータベースが含まれていないこと。
-
インスタンスの利用可能なストレージ容量は、移行するデータファイルのサイズよりも大きい必要があります。ストレージ容量が不足している場合は、インスタンスストレージをスペックアップしてください。
-
-
オンプレミスの SQL Server データベースの復元モードは、
FULLである必要があります。説明-
増分データ移行にはトランザクションログバックアップが必要です。Simple 復元モデルはトランザクションログバックアップをサポートしていません。
-
差分バックアップファイルが大きいと、増分データ移行が長引く可能性があります。
-
-
RAM ユーザーとしてログインする場合、次の要件を満たす必要があります:
-
RAM ユーザーには、AliyunOSSFullAccess および AliyunRDSFullAccess 権限が必要です。詳細については、「RAM を使用した OSS へのアクセスコントロール」および「RAM を使用した RDS へのアクセスコントロール」をご参照ください。
-
ご利用の Alibaba Cloud アカウントが、RDS の公式サービスアカウントに OSS リソースへのアクセスを許可していることを確認してください。
-
Alibaba Cloud アカウントで手動でアクセスポリシーを作成し、それを RAM ユーザーにアタッチする必要があります。
-
事前準備
自己管理データベースで DBCC CHECKDB コマンドを実行し、allocation errors と consistency errors を確認します。期待される出力は次のとおりです。
...
CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxx'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
注意事項
-
移行レベル:このソリューションは単一のデータベースのみを移行します。複数のデータベースまたはすべてのデータベースを移行するには、「SQL Server インスタンスレベルのクラウド移行」をご参照ください。
-
バージョンの互換性:自己管理 SQL Server インスタンスからのバックアップを、それより古い SQL Server バージョンを実行している ApsaraDB RDS for SQL Server インスタンスに復元することはできません。
-
権限管理:ApsaraDB RDS サービスアカウントに OSS へのアクセスを許可すると、Resource Access Management (RAM) に `
AliyunRDSImportRole` という名前のロールが作成されます。このロールを変更または削除しないでください。変更または削除すると、クラウド移行タスクが失敗します。誤ってこのロールを変更または削除した場合は、移行ウィザードを使用して権限を再付与する必要があります。 -
アカウント管理:移行完了後、既存のデータベースアカウントは使用できません。ApsaraDB RDS コンソールで新しいアカウントを作成する必要があります。
-
OSS ファイルの保持:クラウド移行タスクが完了する前に OSS からバックアップファイルを削除しないでください。削除すると、タスクは失敗します。
-
バックアップファイルの要件:
-
ファイル名の制限:バックアップファイル名に特殊文字 (例:`
!@#$%^&*()_+-=`) を含めることはできません。含めると、クラウド移行は失敗します。 -
ファイル拡張子:ApsaraDB RDS は、次の拡張子を持つバックアップファイルをサポートしています:`
.bak` (完全バックアップ)、`.diff` (差分バックアップ)、および `.trn` または `.log` (ログバックアップ)。ApsaraDB RDS は他のファイルタイプを認識しません。説明-
実際には、ファイルの拡張子が必ずしもそのバックアップタイプを示すわけではありません。たとえば、`
.bak` ファイルには、完全バックアップ、差分バックアップ、またはトランザクションログバックアップが含まれている場合があります。 -
ApsaraDB RDS コンソールからダウンロードした SQL Server ログバックアップファイルは、デフォルトで `
.zip.log` 形式になります。これは、ステップ 1 の公式スクリプトで生成される `.bak` バックアップファイルとは異なります。ファイル形式を変換した後、増分クラウド移行にそのファイルを使用できます。処理方法: ファイル拡張子を `
.zip` に変更し、ファイルを解凍します。次に、解凍された `database_name.lbak` ファイルの名前を `.bak` 拡張子に変更します。最後に、この `.bak` ファイルを増分ログバックアップとして OSS にアップロードし、クラウド移行に使用します。
-
-
ワークフロー例
|
移行フェーズ |
ステップ |
説明 |
|
完全データ移行フェーズ |
ステップ 1. 00:00 以前 |
事前準備を完了します:
|
|
ステップ 2. 00:01 |
ソースデータベースの完全バックアップを実行します。所要時間:約 1 時間。 |
|
|
ステップ 3. 02:00 |
バックアップファイルを OSS バケットにアップロードします。所要時間:約 1 時間。 |
|
|
ステップ 4. 03:00 |
ApsaraDB RDS コンソールで、完全バックアップファイルを復元します。所要時間:約 19 時間。 |
|
|
増分移行フェーズ |
ステップ 5. 22:00 |
ソースデータベースの増分ログバックアップを実行し、OSS にアップロードします。所要時間:約 20 分。 |
|
ステップ 6. 22:20 |
ログバックアップファイルを復元します。所要時間:約 10 分。 |
|
|
ステップ 7. 22:30 |
|
|
|
切り替え |
ステップ 8. 22:34 |
最終ログバックアップは約 4 分で復元されます。その後、データベースをオンラインにできます。 |
|
ステップ 9. 22:35 |
データベースはオンラインです。DBCC チェックを非同期で実行することを選択した場合、この最終ステップには約 1 分かかります。 |
このワークフローは、必要なアプリケーションのダウンタイムが非常に短いことを示しています。最終ログバックアップの直前にアプリケーションの書き込みを停止するだけで済みます。この例では、合計ダウンタイムは 5 分未満です。
ステップ 1: ローカルデータベースのバックアップ
-
バックアップスクリプトをダウンロードし、SSMS で開きます。
-
次のパラメーターを変更します。
パラメーター
説明
@backup_databases_list
バックアップするデータベースのリストをセミコロンまたはカンマで区切って指定します。
@backup_type
実行するバックアップのタイプ。有効な値:
-
FULL: 完全バックアップ
-
DIFF: 差分バックアップ
-
LOG: ログバックアップ
@backup_folder
バックアップファイルのローカルディレクトリ。このディレクトリが存在しない場合、スクリプトは自動的に作成します。
@is_run
バックアップを実行するかどうかを決定します。有効な値:
-
1: バックアップを実行します。
-
0: チェックのみを実行し、バックアップは実行しません。
-
-
バックアップスクリプトを実行します。
スクリプトは、選択したバックアップタイプに関係なく、デフォルトで `
.bak` ファイルを生成します。
ステップ 2: バックアップファイルの OSS へのアップロード
-
バックアップファイルを OSS にアップロードするには、まずバケットを作成する必要があります。
-
すでに OSS にバケットがある場合は、次の要件を満たしていることを確認してください:
-
OSS にバケットがない場合は、作成します。 (OSS を有効化していることを確認してください。)
-
OSS コンソールにログインし、バケット をクリックし、次に Create bucket をクリックします。
-
次の主要なパラメーターを設定します。他のパラメーターはデフォルト値のままにします。
重要-
バケットはこのデータ移行にのみ使用され主要なパラメーターのみを設定する必要があります。移行が完了したら、データ漏えいを防ぎ、関連する料金を回避するために、バケットを速やかに削除してください。
-
バケットを作成する際にデータ暗号化を有効にしないでください。
パラメーター
説明
例
バケット名
バケットの名前。名前はグローバルに一意である必要があり、バケット作成後は変更できません。
命名規則:
-
小文字、数字、ハイフン (-) のみを含めることができます。
-
小文字または数字で開始および終了する必要があります。
-
長さは 3~63 文字である必要があります。
migratetest
地理
バケットが存在するリージョン。ECS インスタンスからのアップロードと RDS インスタンスへの復元に内部ネットワークを使用するには、ECS インスタンス、バケット、および RDS インスタンスが同じリージョンにある必要があります。
中国 (杭州)
ストレージタイプ
標準ストレージ を選択します。このトピックで説明されている移行方法は、他のストレージクラスのバケットをサポートしていません。
標準
-
-
-
-
バックアップファイルを OSS にアップロードします。
ローカルデータベースをバックアップした後、バックアップファイルを RDS インスタンスと同じリージョンにある OSS バケットにアップロードします。これにより、内部ネットワーク経由での通信が可能になり、インターネットトラフィック料金を回避し、アップロード速度を向上させることができます。次のいずれかの方法を使用できます:
ステップ 3: クラウド移行タスクの作成
[インスタンス] ページに移動します。上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。次に、RDS インスタンスを見つけて、インスタンスの ID をクリックします。
-
左側のナビゲーションウィンドウで、復元 をクリックします。
-
ページの上部で、OSS バックアップデータをクラウド上で復元する をクリックします。
-
インポートガイド ページで、次へ を 2 回クリックして、[データのインポート] ステップに進みます。
説明OSS バックアップデータを RDS に移行する機能を初めて使用する場合は、RDS アカウントに OSS へのアクセスを許可する必要があります。権限付与 をクリックして必要な権限を付与してください。そうしないと、OSS バケット ドロップダウンリストは空になります。
-
次のパラメーターを設定し、決定 をクリックします。
クラウド移行タスクが完了するのを待ちます。更新 をクリックして、タスクの最新のステータスを表示します。タスクが失敗した場合は、タスクの説明にあるエラーメッセージに基づいて問題をトラブルシューティングします。詳細については、「よくあるエラー」をご参照ください。
パラメーター
説明
データベース名
RDS インスタンス上のターゲットデータベースの名前。名前は SQL Server の命名規則に準拠する必要があります。
重要-
移行を開始する前に、ターゲットインスタンスにバックアップファイル内のデータベースと同じ名前の既存のデータベースまたはアタッチされていないデータベースファイルがないことを確認してください。
-
バックアップファイルで指定されたデータベースと同じ名前のデータベースがターゲットインスタンスにすでに存在する場合、または同じ名前のアタッチされていないデータベースファイルが存在する場合、クラウド移行は失敗します。
OSS バケット
バックアップファイルが保存されている OSS バケットを選択します。
OSS ファイル
虫眼鏡アイコンをクリックして、プレフィックスによるバックアップファイルのあいまい検索を実行します。結果には、ファイル名、ファイルサイズ、最終更新日時が表示されます。移行するバックアップファイルを選択します。
クラウド移行計画
[データベースを開かない] を選択します。
-
即時アクセス (完全バックアップ):移行する単一の完全バックアップファイルがある場合、クラウドへの完全データ移行にこの方法を使用します。このオプションでは、`CreateMigrateTask` 操作は次のパラメーターを使用します:`
BackupMode = FULL` および `IsOnlineDB = True`。 -
アクセス保留 (増分バックアップ):完全バックアップファイルの後に差分バックアップまたはログファイルを移行する場合、クラウドへの増分データ移行にこの方法を使用します。このオプションでは、`CreateMigrateTask` 操作は次のパラメーターを使用します:`
BackupMode = UPDF` および `IsOnlineDB = False`。
-
ステップ 4: 差分バックアップまたはログバックアップのインポート
自己管理 SQL Server データベースの完全バックアップを移行した後、差分バックアップまたはログバックアップファイルをインポートします。
[インスタンス] ページに移動します。上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。次に、RDS インスタンスを見つけて、インスタンスの ID をクリックします。
-
左側のナビゲーションウィンドウで 復元 をクリックし、次に バックアップデータのアップロード履歴 タブをクリックします。
-
タスクリストで対応するタスクを見つけ、[操作] 列の 増分ファイルのアップロード をクリックします。増分ファイルを選択し、OK をクリックします。
説明-
複数のログバックアップファイルがある場合は、それぞれに個別の移行タスクを作成します。
-
最終バックアップファイルが 500 MB を超えないようにしてください。これにより、増分クラウド移行に必要な時間が最小限に抑えられます。
-
最終ログバックアップファイルを生成する前に、自己管理データベースへのすべての書き込み操作を停止してください。これにより、自己管理データベースと RDS for SQL Server インスタンス間のデータ整合性が確保されます。
-
ステップ 5: データベースのオープン
バックアップファイルをインポートした後、ApsaraDB RDS for SQL Server インスタンス上のデータベースは `In Recovery` または `Restoring` 状態になります。高可用性版インスタンスの場合、状態は `In Recovery` で、ベーシック版インスタンスの場合、状態は `Restoring` です。どちらの状態でも、データベースは読み取りおよび書き込み操作には使用できません。データベースを利用可能にするには、データベースを開く必要があります。
[インスタンス] ページに移動します。上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。次に、RDS インスタンスを見つけて、インスタンスの ID をクリックします。
-
左側のナビゲーションウィンドウで、復元 を選択し、次に クラウド上へのデータバックアップの記録 タブをクリックします。
-
タスクリストで、バックアップファイルインポートのレコードを見つけ、[操作] 列の データベースを開く をクリックします。
-
データベース整合性チェックオプションを選択し、決定 をクリックします。
説明データベース整合性チェックには、次のオプションがあります:
-
非同期 DBCC:このオプションは、データベースが開いた後に `DBCC CHECKDB` 操作を非同期で実行します。この方法は、データベースをより速くオンラインにすることでダウンタイムを最小限に抑えます。データベースが大きく、`DBCC CHECKDB` 操作に時間がかかる場合に最適です。サービスのダウンタイムに敏感で、チェックの即時結果が必要ない場合にこのオプションを使用します。CreateMigrateTask API 呼び出しでは、このオプションは `CheckDBMode` パラメーターを `
AsyncExecuteDBCheck` に設定します。 -
同期 DBCC:このオプションは、データベースが開くときに `DBCC CHECKDB` 操作を実行します。この方法により、データ整合性を即座に検証し、エラーを特定できます。データ検証を優先する場合にこのオプションを使用しますが、データベースを開くのにかかる時間が増加することに注意してください。CreateMigrateTask API 呼び出しでは、このオプションは `CheckDBMode` パラメーターを `
SyncExecuteDBCheck` に設定します。
-
ステップ 6: クラウド移行バックアップ詳細の表示
クラウド移行タスクのバックアップファイルの詳細を表示するには、RDS インスタンスの左側のナビゲーションウィンドウにある 復元 ページに移動します。クラウド上へのデータバックアップの記録 タブで、タスクを見つけ、右端の列にある ファイルの詳細を表示します をクリックします。
クラウド移行後、システムは RDS インスタンスの自動バックアップポリシーに基づいて自動的にバックアップを作成します。このバックアップは指定されたバックアップ時間に実行され、調整可能です。結果のバックアップセットには移行されたデータが含まれ、復元 ページで利用できます。
次のスケジュール時刻より前にバックアップが必要な場合は、手動バックアップを実行できます。
よくあるエラー
完全バックアップデータ移行中の一般的なエラーについては、「完全バックアップデータ移行における一般的なエラー」をご参照ください。
増分アップロード中に次のエラーが発生することがあります:
-
データベースを開けませんでした
-
エラーメッセージ:データベース xxx を開けませんでした。
-
原因:ソース SQL Server データベースが、選択した ApsaraDB RDS for SQL Server インスタンスエディションでサポートされていない高度な機能を使用しています。たとえば、ソース SQL Server インスタンスが Enterprise Edition でデータ圧縮またはパーティショニングが有効になっており、データを Web Edition を実行する ApsaraDB RDS for SQL Server インスタンスに移行する場合にこのエラーが発生します。
-
解決策:
-
ソース SQL Server インスタンスで高度な機能を無効にし、新しいバックアップを作成してから、再度移行を試みてください。
-
ソースインスタンスと同じ SQL Server エディションの ApsaraDB RDS for SQL Server インスタンスを購入してください。詳細については、「ApsaraDB RDS for SQL Server インスタンスの作成」をご参照ください。
説明詳細については、「異なる SQL Server バージョンと RDS エディション間の機能比較」をご参照ください。
-
-
-
バックアップチェーンの LSN の不一致
-
エラーメッセージ:このバックアップセットのログは LSN XXX から始まりますが、これはデータベースに適用するには新しすぎます。RESTORE LOG は異常終了しています。
-
原因:SQL Server では、差分バックアップまたはログバックアップは、その開始ログシーケンス番号 (LSN) が以前に復元されたバックアップファイルの LSN と一致する場合にのみ復元できます。LSN が一致しない場合にこのエラーが発生します。
-
解決策:増分アップロード用に LSN が一致するバックアップファイルを選択してください。バックアップファイルは時系列順にアップロードするようにしてください。
-
-
非同期 DBCC CHECKDB の失敗
-
エラーメッセージ: 非同期 DBCC checkdb 失敗: CHECKDB はテーブル 'XXX' (オブジェクト ID XXX) で 0 個のアロケーションエラーと 2 個の整合性エラーを検出しました。
-
原因:バックアップファイルが ApsaraDB RDS for SQL Server インスタンスに復元された後、システムは非同期 DBCC CHECKDB を実行します。このチェックが失敗した場合、ソースデータベースにすでに整合性エラーが含まれていたことを示します。
-
解決策:
-
移行先の ApsaraDB RDS for SQL Server インスタンスで、次のコマンドを実行します:
DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)重要この修復コマンドはデータ損失を引き起こす可能性があります。
-
ソースインスタンスで次のコマンドを実行してエラーを修復し、増分アップロードを再試行します。
DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)
-
-
-
増分アップロード用のバックアップファイルタイプが正しくない
-
エラーメッセージ:バックアップセット (xxx) はデータベースの完全バックアップです。トランザクションログまたは差分バックアップのみを受け付けます。
-
原因:ApsaraDB RDS for SQL Server インスタンスへの増分アップロード中、システムは完全バックアップが復元された後、ログバックアップファイルまたは差分バックアップファイルのみを受け付けます。再度完全バックアップファイルを選択した場合にこのエラーが発生します。
-
解決策:ログバックアップファイルまたは差分バックアップファイルを選択してください。
-
-
データベース数が制限を超えています
-
エラーメッセージ:データベース (xxx) の移行は、データベース数の制限により失敗しました。
-
原因:データベースを最大データベース数に達したインスタンスに移行しようとすると、このエラーが発生します。
-
解決策:データベースを別の ApsaraDB RDS for SQL Server インスタンスに移行するか、現在のインスタンスから不要なデータベースを削除してください。
-
-
RAM ユーザーの権限が不十分
-
Q1: 「データ移行タスクの作成」のステップ 5 で、すべてのパラメーターが設定されているにもかかわらず、決定 ボタンがグレーアウトしてクリックできないのはなぜですか?
-
A1: これは、RAM ユーザーに必要な権限がない場合に発生する可能性があります。このトピックの前提条件セクションを参照し、必要な権限を付与してください。
-
Q2: RAM ユーザーが `
AliyunRDSImportRole` を付与しようとしたときに発生する `no permission` エラーを解決するにはどうすればよいですか? -
A2: Alibaba Cloud アカウントを使用して、RAM ユーザーに一時的に `
AliyunRAMFullAccess` 権限を付与してください。RAM ユーザーに権限を付与する手順については、「RAM を使用して ApsaraDB RDS の権限を管理する」をご参照ください。
-
-
増分バックアップが誤った完全バックアップに復元された
-
エラーメッセージ:この差分バックアップは、データベースが正しい状態にないため復元できません。RESTORE DATABASE は異常終了しています。
-
原因:新しい増分バックアップが古い完全バックアップに復元された場合にこのエラーが発生します。これにより、差分バックアップファイルの LSN が `NORECOVERY` オプションで復元された完全バックアップファイルの LSN と一致しないため、バックアップチェーンが壊れます。
-
解決策:正しいバックアップファイルを選択し、正しい順序でアップロードしていることを確認してください。ソースインスタンスの `
msdb.dbo.backupset` テーブルをクエリして、完全バックアップファイルと差分バックアップファイルの順序と LSN の関係を確認できます。
-
-
複数ファイルのストライプバックアップに関するエラー
-
エラーメッセージ:(xxx.bak) の検証に失敗しました。エラーメッセージ:メディアセットには xxx 個のメディアファミリーがありますが、1 つしか提供されていません。すべてのメンバーを提供する必要があります。VERIFY DATABASE は異常終了しています。
-
原因:ソースデータベースはストライプバックアップ機能を使用してバックアップされており、1 つの完全バックアップが複数の .bak ファイルに書き込まれています。しかし、移行タスクにはこれらのファイルのうち 1 つしか提供されていません。ApsaraDB RDS for SQL Server は、単一のタスクで複数のバックアップファイルからのデータ移行をサポートしていません。
-
解決策:ソースデータベースを単一の .bak ファイルにバックアップし、再度アップロードを試みてください。
-
API リファレンス
|
API |
説明 |
|
OSS からのバックアップファイルを ApsaraDB RDS for SQL Server インスタンスに復元することで、データ移行タスクを作成します。 |
|
|
データ移行タスクの一部として復元されたデータベースをオンラインにします。 |
|
|
ApsaraDB RDS for SQL Server インスタンスのデータ移行タスクを一覧表示します。 |
|
|
データ移行タスクのバックアップファイルの詳細を返します。 |

をクリックし、アップロードするバックアップファイルを選択して、[開く] をクリックします。