IT技術 データベース ミドル・ウェア

DBの移行を考える

2020年2月24日

DBの移行に関するメモです。

DBソフトウェア(DBMS/DMS ※1) によって移行の方法は異なってくるので、移行時にはソフトウェア毎の詳細な調査が必要になると思います。

このメモはジェネラルな内容についてなので記載としてはフワッとした内容になっています。

※1)  Database Management System の略は DBMS と DMS の2種類があるようです。私は癖と言うか周辺の人の影響で DBMS と呼んでいます。

DB 移行の手順 (作業計画)

実施には細かい計画と検証環境での手順テスト / 切り戻し手順の確立が必用になる。
特に移行前と移行後の DB製品が別の場合は、作業範囲が膨らむ。

  • 移行のための事前調査
  • 新環境での運用計画の策定(監視、バックアップ)
  • 移行計画・切り戻し計画の策定
  • 移行のための開発  (表の作成 / データ型の調整 /ストアードプロシジャーなどの調整 /移行手順、切り戻し手順の確認)
  • データ移行作業
  • データの整合性チェック
  • アプリケーションの動作確認
  • アプリケーションの切り替え(新規 DB側に接続)
参考

オフライン移行 (典型的な停止時間の大きい移行)

DBのデータをエクスポートして、別のDBにインポートする方法。DBに互換性があるのであればバックアップ / リストアもある。
データの物理移行に時間がかかるため、データの移行の間はシステムが使えなくなる。
データが大量にある場合は、どうしても時間がかかってしまう事は避けられない。

別の種類の DBソフトウェア に移行する時は、途中にデータのフォーマットの変換などをしないといけず、オフライン移行しか選択肢は無い。
はじめの計画からかなりの時間がかかる事が想像される。

作業の概要

1. アプリケーションの停止 (移行元の DBを停止)
2. 移行元の DBのデータの Export (Backup)
3. 移行先の DBにバックアップデータをコピー
4. 移行先の DBにデータを Import (Restore)
5. Application の接続先を新しい DB に ( 移行先の DBを起動)

  • 検証環境にデータを移行する手順と同じだとイメージすれば良い。
  • Backup / Restore を使う方法と Export / Import を使う方法がある。
  • 事前にフルバックアップだけは移行しておき、その後の差分だけを後から移行する事で短時間で移行できる可能性もある
  • 移動させるデータが大きいため、移行作業に時間がかかり停止時間も長くかかるため、Export / Import の速度や、データ移動の際の帯域を計算し移行時間を計算しておく
  • データ量が多すぎて、そもそもデータを Export するディスク領域が無かった。という事に遭遇する事がよくある気がする・・・

この手順も Microsoft SQL Server 等では、標準の機能でGUI から移行先のノードを選ぶだけで簡単にできる。(個人的には MS SQL Server は、運用者視点でいろいろ一番便利に作られている印象を持っている)

異なる DB製品間の移行

基本的に、異なる DB製品間の移行は、このオフライン(停止時間をたっぷり?取った)移行になる。

詳細は把握できていないが、AWS Database Migration Serviceのようなデータ移行サービスをパブリック・クラウド事業者が提供している場合もある。

但し、AWS Database Migration Service のガイドを読むと「AWS DMS migrates data, tables, and primary keys to the target database. All other database elements are not migrated.」とある。基本的に中間サーバーでスキーマーを変換して、新しいDBにデータをできるだけ送り組むための機能で、アプリケーションサーバー周りは作り直しをする必用がある。

また DB製品毎に使われている SQL には「方言」があり、この方言が移行の妨げになる。DB製品間の移行で問題になる Query を検出してくれるツールも存在している。

SQL の違いは、アプリケーションサーバーの複雑な改修を要求するので、テストを含め大規模な移行になる事を覚悟する。

参考リンク:

停止時間をできるだけ小さくする移行

実稼働中もレプリケーションなどを使い継続的にデータをコピーしながら、「ほぼ」無停止で移行する方法。ダウンタイムを大きく圧縮できる

ただし、データの移行の「開始」と「完了」時に「静止点」を作る必用があるので、無停止にはならない。

基本的に、同じ DBMS間のみで使えるが、異 DBMS間のデータレプリケーションを行う 3rd Party ツールも存在するらしい(深くは調査していないがストアードプロシジャーなどは変換できないと思うが・・・かなりダウンタイムを減らす事ができると思う)。移行前と移行後のDBMSが同じであれば、アプリケーションサーバーの改修は接続先の変更だけで収まる。

稼働中に元のDB (製品によってはバージョン違いなどもサポート)から新しいDBに継続的コピーを取得しておき、切り替え直前に「Application」を停止しデータを止めた後、残りのデータもコピーした後、アプリケーションサーバー側を、コピー先に切り替える。

MySQL 等では、マスター/スレイブ (プライマリ / セカンダリ) 構成を組んでおいて、データの同期が終わったらスレイブ側をマスターに昇格させる。

MySQL  / Microsoft の MS SQL / DB2 の HADR など DBのレプリケーション機能を持った DBソフトウェアでこれが可能

この方法で一般的に気を付ける部分は

  • 移行元と移行先の DB が同じ DBMS (バージョンの差はカバーされるケースがある)
  • APサーバーの接続先の切り替え作業が必用(これはどの移行方法でも基本的に同じ)
  • データの「静止点」を取るための停止時間は必用

参考リンク:

仮想化の機能を使用した移行 (VMware による無停止移行)

いろいろ考えているうちに、こういうパターンもあるな。と思いついたので。
仮想化インフラの部分の話になるので、DBMSレベルでは気にする事は無い。OSレベルから全て管理している VMware だからできる荒技。

移行中は、HWの負担が大きいので、大きなDBの場合現実的では無いかもしれない。メンテナンス時間中でDBの容量が小さかったりすれば問題は無いと思う。

→ アプリケーションの停止は必用無い
→ 最新のHWを追加して同じクラスタに追加した後、vMotion で新規 HW に移動させる。
→ vMotion は高負荷なのでレスポンスが悪くなる一時的にエラーになる可能性は考える必用がある。VMware は途中から共有ディスクの無いvMotionにも対応したが、DBで実際にこれをやる事が IO的な観点でどのくら影響を与えるかは、移行するDB毎に見積もる必用があると思う。

  • VMware の Storage vMotion で、ストレージ筐体 (DataStore) のみを移動する事もできる。

 

vMotion のネットワーク要件は、250Mbps で、遅延は往復で 150ms までサポートされる。(150msec であれば東京-大阪間が行ける気がする・・・)

意外に寛大でびっくりしたのだが、 vMotion に時間がかかると思うので、150ms は、あくまでギリギリのスペックと理解。

created by Rinker
¥113 (2024/12/04 22:36:55時点 Amazon調べ-詳細)

ストレージ HW の機能を使った移行 (停止時間を最小にする移行)

ストレージHWが持っているボリュームのコピー機能を使う。

多くのストレージHWは、ストレージHWが管理するボリューム単位で別筐体に SAN or  IPネットワーク経由で コピーする機能を持っている。

物理的な遅延の制限(ストレージ筐体間の物理距離)で「同期コピー」と「非同期コピー」がある。

ストレージ製品のグレードによって使用できる機能が敢えて絞られている場合もあるが、物理的な遅延が少なければ「同期コピー」(コピー元とコピー先のボリュームに差分は無い)が理論的には使用でき、ボリューム感の遅延が無視できないくらい大きいと「非同期コピー」となる。

「非同期コピー」の場合は、データの同期が完了次第、コピー先のボリュームが使えるようになる。

「非同期コピー」の場合、切り替え時にアプリケーションを短い時間静止させる必用がある。

  1. ソース側のアプリケーションを停止
  2. ボリュームのコピーの完了を待つ
  3. ターゲット側のアプリケーションに切り替え

基本的にストレージベンダーに依存する機能なので、ストレージ製品毎に調べる必用がある。でも、大体似たような機能を持っている。

  • Storage HW の機能を使用し、DBが入ったボリュームのレプリーションを作成する
    → 昔はハイエンドのストレージのみ遠隔レプリケーションの機能を持っていたが、ミッドレンジでも一般的になりつつある。
  • 大量のデータをネットワークを通じて送信するとネットワークの帯域で送りきれない事も発生するので、差分転送や重複排除を行いデータ容量を抑えるソリューションもある。
  • 同期コピーの場合は、100km 程度が物理的な限界 (それ以上は遅延が大きく、レプリカに書き込んで戻ってくるのに時間がかかる)

関連リンク:

アプリケーションの接続先の変更時の考慮

移行先環境の DBは、別ドメインで作成していると思うので、アプリケーション側の接続先を DB移行にともなって書き換える必用がある。

A) アプリケーション側のドメインを移行先のドメインに書き換える。
アプリケーション側の変更が必用なので大変かもしれない。

B) 権威DNSサーバーで、移行元DBのFQDN の IP アドレスを、移行先 DBの FQDN IPアドレスに置き換える
→切り替えも切り戻しも簡単 (切り替えの少し前からFQDN の TTL を短くしておかないとなかなか切り替わらないし、切り戻しも大変

プライベート環境から AWS 等のクラウド環境へのDB移行

クラウドベンダーから手順が出たてりするが、DB の移行自体は、前述したどれかの方法になる。オンプレとクラウドの間の移行だからと言っても基本は同じになる。

もし既存がプライベート環境で社内の人間しかアクセスしないような DB であれば、AWS等の VPC を完全に外部に閉じた状態で、VPN もしくは専用線で社内ネットワークと連結する必用がある(この作業が環境作りの 1st STEPになると思う)

クラウド各社の VPN ソリューション

VPN接続の場合は、オンプレ側に設置する VPN 装置の MTU 値を正しく設定しないとパフォーマンスが著しく劣化する事がある。

-IT技術, データベース, ミドル・ウェア

Copyright© エンジニアの何でもメモ帳 , 2024 All Rights Reserved.