ネイティブ SQL Server バックアップ/リストア

Microsoft SQL Server データベースは、フルバックアップおよび差分バックアップ (.bak) ファイル、あるいは差分リストアおよびログ・リストアを使用するネイティブ・バックアップおよびリストア操作をサポートします。 ネイティブ .bak ファイルを使用することは、 SQL Server データベースをバックアップおよび復元する最も簡単な方法であり、インスタンス内の単一または複数のデータベースの単純な移行方法です。 既存のサーバー上のデータベースのフルバックアップが取得され、 IBM Cloud Object Storage バケットにコピーされます。 その後、 s3fs または クローン と SMB\Samba 共有を持つステージング・サーバーを介して、 IBM Cloud VPC内の SQL Server データベース・インスタンス仮想サーバー上にリストアされます。

トランザクション複製

トランザクション複製を使用すると、1 つのデータベースと別のデータベースの間で変更を転送できます。 これらの変更には、データ、表、ストアード・プロシージャー、ビューなどが含まれます。 このアーキテクチャーは、以下のもので構成されます。

• パブリッシャー-データを公開する 1 次データベース。
• 購読者-複製データを受信する 2 次データベース。
• ディストリビューター-トランザクション・レプリケーション用のメタデータとトランザクションを保管するサーバーで、パブリッシャーまたはサブスクライバーにとって理想的には別個のサーバーです。

このプロセスは、以下のように機能します。

• トランザクション複製は、パブリケーション・データベース内のオブジェクトとデータのスナップショットを作成し、それをサブスクライバー・データベースに送信します。 スナップショットがサブスクライバー・データベースに適用されます。
• パブリッシャーで行われたデータ変更およびスキーマ変更は、それらが発生した順序でサブスクライバーに送信され、同じ順序でサブスクライバーに適用されます。
• 2 つのデータベースが同期化され、保守時間枠に入ると、以下のようになります。
  • パブリッシャーへのアクセスをすべて停止します。
  • 複製が完了したことを確認します。
  • サブスクリプションを削除します。
  • サブスクライバーであったものへのアクセスを有効にします。
  • パブリッシャーの機能を廃止します。

詳しくは、 トランザクション・レプリケーション を参照してください。

データベース・ミラーリング

データベース・ミラーリングは SQL Server 2012 で非推奨になりましたが、引き続き SQL 2019 の資料で参照されています。 SQL Serverを参照してください。 ここでは、マイグレーション方式の完全性について説明しますが、マイグレーションで使用する場合は、この方法を慎重に検討してください。

SQL Server でのデータベース・ミラーリングにより、 SQL Server データベースのコピー (ミラー) をスタンバイ・サーバーに保持することができます。 ミラーリングにより、データの 2 つの別個のコピーが常に存在することが保証されます。 ログ・シッピングと比較すると、データベース・ミラーリングはセットアップが少し複雑になり、制限が増えます。 協力関係にある両方のサーバーが同じ Windows ドメインにある場合は、データベース・ミラーリングのセットアップが容易になりますが、そうでない場合は、エンドポイント認証に証明書を使用できます。 マイグレーションの基本ステップには、以下のものがあります。

• データベース・ミラーリングを構成します。
• 必要な時間の経過後に、1 次サーバー上の基本データベースを使用しているアプリケーションを停止します。
• 各データベースが同期状態であることを確認してください。
• ミラーリングされた各ユーザー・データベースをフェイルオーバーします。
• ミラーリング協力関係を除去します。
• アプリケーションを新しいデータベース・サーバーにリダイレクトします。
• 元のサーバーを廃止します。

ログ配送

SQL Server のログ・シッピングは、データベース・レベルで構成できます。指定された期間内に、 SQL Server のトランザクション・ログ・バックアップが作成され、宛先サーバーにコピーされて、リストアされます。 トランザクション・ログには、 SQL Server データベースで発生したすべてのトランザクションのログが含まれます。 トランザクション・ログ・バックアップのシップ元の SQL Server インスタンスは 1 次インスタンスと呼ばれ、トランザクション・ログ・バックアップのシップ先の SQL Server インスタンスは 2 次インスタンスと呼ばれます。 ログ・シッピングを構成する前に、データベースは完全リカバリー・モデルまたはバルク・ログ・モードでなければなりません。

SQL Server トランザクション・ログ・バックアップ設定では、ネットワーク・パスへのアドレス指定が可能であり、バックアップ・ジョブを実行するためにバックアップ・ジョブ・スケジューラーを定義できます。デフォルトでは、この設定は 15 分ごとにバックアップ・ジョブを実行することです。 データベース・バックアップがスケジュールされると、2 次サーバーでリカバリーする必要があるデータベースのフルバックアップが 1 つ作成されます。 保守時間中に、1 次サーバーから 2 次サーバーへの切り替えを実行できます。ログ・シッピングは無効になり、1 次サーバーは廃止されます。

常時稼働の可用性グループ

SQL Server Always On 可用性グループは、高可用性と災害復旧のソリューションを提供し、 SQL Server 2012 以降のバージョンで使用できます。 この機能を使用すると、ダウン時間を最小限に抑えながら、既存の SQL Server データベースを IBM Cloud にマイグレーションできます。 「常にオン」可用性グループを持つ既存の Windows Server Failover Cluster がある場合は、非同期複製を使用して追加の 2 次レプリカを作成することにより、マイグレーション中にクラスターを一時的に拡張することができます。 保守期間中に、手動フェイルオーバーを実行して、切り取りを有効にすることができます。

常時稼働の分散可用性グループ

SQL Server Always On 分散可用性グループは、2 つの異なる可用性グループにまたがっています。 各可用性グループは、2 つの異なる Windows Server Failover Clusters (WSFC) 上で構成されます。1 つはソース・ロケーションにあり、もう 1 つは IBM Cloud VPCにあります。 オペレーティング・システムと SQL Server のバージョンは、WSFC および可用性グループをサポートできる限り、同じバージョンである必要はありません。 このマイグレーション方式は、ミッション・クリティカルな SQL Server データベースを再ホストするのに適しています。 分散可用性グループ・アーキテクチャーは効率的なデータ転送方式です。これは、1 次レプリカが IBM Cloud内のフォワーダー・レプリカのみにデータを転送し、フォワーダーが IBM Cloud内の 2 次レプリカとデータを同期する役割を担います。 標準的なアーキテクチャーは以下のとおりです。

• ソース WSFC クラスターは、Always On 可用性グループをホストし、2 つのノードを持ち、自動フェイルオーバーを使用する同期複製を使用します。
• IBM Cloud でホストされるターゲット WSFC クラスターには、Always On 可用性グループがあり、2 つのノードがあります。1 つはマルチゾーン・リージョン (MZR) の可用性ゾーン (AZ) にあり、自動フェイルオーバーを使用する同期複製を使用します。
• ネットワーク接続 (通常は直接リンク接続) は、2 つのクラスターを接続します。
• Always On 分散可用性グループが構成され、ソース WSFC クラスターの 1 次レプリカからターゲット WSFC クラスターの 1 次レプリカ (フォワーダー) にデータが転送されます。
• フォワーダーは、ターゲット WSFC クラスター内の 2 次レプリカにデータを転送する責任があります。

保守期間中に、手動フェイルオーバーを実行してカットオーバーを有効にし、ターゲット WSFC 内の 1 次データベースをアプリケーションからの読み取り/書き込みアクセスのソースにすることができます。

詳しくは、 分散可用性グループを参照してください。