ビジネスデータをクラウドに移行する際の技術的な考慮事項

序文

JDグループ社内およびJD Cloudのお客様のJD Public Cloud、JD Private Cloud、JD Government Cloudへの業務移行をサポートする過程で、JD Technology-JD Cloud Business Group-Technical Service Groupは、関連業務システムのデータ移行に関する管理および技術経験を蓄積してきました。これらの経験を事例の形で皆様と共有し、皆様の業務移行作業のお役に立てれば幸いです。

移行前の準備

ビジネスをクラウドに移行するには、次のようなさまざまなビジネスデータが関係します。

データベース:

リレーショナルデータベース MySQL、PG、Oracle など

オブジェクトストレージ:

標準 S3 インターフェイスオブジェクトストレージ移行ミドルウェアデータ: ES、mongoDB、redis など。

ファイルストレージ:

文書や画像などの非構造化データ

ビッグデータ:

HBASE、HDFS ファイルなど。

JD Cloud の社内および社外の顧客のクラウド移行プロセスでは、ほとんどのビジネスで上記の複数のデータタイプが関係します。関連する移行事例から蓄積された経験に基づき、データ移行を開始する前に、少なくとも次のように準備する必要があります。

1. 明確な移行操作手順（移行前の準備、移行操作、移行後の検証）、実行者、確認者を含む、実行可能なデータ移行技術計画が策定されている。

2. 移行緊急計画および削減計画を策定し、責任マトリックスを明確にし、異常事態に対する意思決定条件と意思決定者を確認します。

3. データセキュリティレベルを確認し、データ移行計画が準拠し安全であることを確認し、関連するビジネスセキュリティ部門のレビューに合格します。

4. 移行期間とカットオーバーデータ同期ウィンドウを評価し (POC 検証データ情報に基づく)、各ビジネスとデータ移行のオプションの 2 番目のプランを確認します。

5. ネットワーク帯域幅と品質が移行要件を満たしていることを確認します。

ケーススタディ

以下に、さまざまなデータ移行シナリオに関するいくつかのケースを示します。

1. リレーショナルデータベース

マイグレーション:

MySQL は移行において最も一般的であり、公式ツールや mysqldump などの関連オープンソースツールを含む、非常に成熟した移行ツールとソリューションも備えています。各クラウドベンダーには独自の DTS 移行ツールもあります。

DTS ツール:

DTS サービスは、送信、同期、データ検証などの手順である程度抽象化を実現しています。比較的使いやすいインタラクティブインターフェイスを備えており、複数のタスクを並行して実行できます。スムーズな移行が必要なシナリオでは、自動化の利点があり、多くの人手を節約できます。一部の DTS ツールでは、バージョン間の移行を実現できます。

DTS の制限は次のとおりです。

（１）ソースデータベース、ターゲットデータベース、DTS管理サービスIPネットワークが相互接続されており、安定したネットワーク接続が確保されている。

（２）移行後の増分同期機能を実装するには、データベースが一定の前提条件を満たしている必要がある。通常の要件は、REPLICATION SLAVE、REPLICATION などの権限要件です。同時に、ストアドプロシージャと関数は、フル + 増分シナリオには含まれません。完全な移行フェーズでは、Alter Table および Drop Table DDL 操作はサポートされません。 **メーカーによってツールの制限が異なる場合があります。製品の説明を注意深く読み、POC を通じて機能を検証する必要があります。

mysqldump ツール:

適切なシナリオでは、ソースデータベースと宛先データベース間のネットワーク接続が良好でない場合、またはネットワーク接続がない場合でも、一定時間の業務中断が許容されます。この場合、ダウンタイム期間中にデータをエクスポートおよびインポートする方が適切なソリューションです (ホストレベルの管理および制御機能がある場合は、データベースホスト全体をミラーリング方式で直接移行することも実行可能な移行方法です)。

MySQL ダンプのエクスポートおよびインポート速度は DTS よりも高速です (ローカル操作で、DTS と比較すると中間リンクが少ない) が、データファイルを圧縮してネットワークまたはモバイルメディア経由で送信するのに時間がかかります。

streamset などの他のオープンソースおよび商用ツールは、MySQL から異種データベースへの同期をサポートできます。これらは非常に強力ですが、多くの制限もあります。

移行所要時間の見積もり:

サービスの切り替えプロセスでは、ビジネスデータの移行と同期が切り替え前の重要なステップとなります。また、このリンクは時間がかかり、エラーが発生しやすいため、カットオーバーの遅延や失敗につながる可能性があります。したがって、データの移行と同期に必要な時間を正確に見積もる必要があります。

データベースの同期は、すべてのデータを移行するためのテーブルレベルの同時実行です。したがって、DTS は、実際のデータ型、データ行の数、ネットワーク帯域幅、ネットワーク待機時間、同期インスタンスの仕様、データベーステーブルの数、単一のデータベーステーブルのサイズなどの要素に基づいて期間を評価する必要があります。

たとえば、データベースのサイズが 500 GB で、テーブルが 5 つあり、そのうち 1 つは 400 GB、残りの 4 つのテーブルはそれぞれ 25 GB です。 1 つのテーブルが 400 GB と比較的大きいため、移行時間は長くなります。 100Gテーブルが5つある場合は移行時間が短縮されます。

通常、本番データを正式に移行する前に、テスト環境の移行 POC を実施し、切り替えプロセスと本番環境の所要時間を検証および評価します。本番業務の切り替え計画を策定する際には、この時間をデータベース移行期間の基準として使用する必要があります。

JD Cloud DTS のデータ移行および同期アーキテクチャは次のとおりです。

ケース1

競合他社のパブリッククラウドから JD.com のパブリッククラウドに移行します。 DTS 移行から手動移行への変換は、ソース側の binlog の問題によって発生しました。

プロジェクトの条件によると、業務のダウンタイムは 8 時間であるため、移行テクノロジソリューションでは DTS と手動データベースインポートの両方がオプションソリューションとなります。 DTS のノンストップサービスとデータ増分機能の特性を考慮して、ダウンタイム前に JD Cloud DTS サービスを通じて履歴データを同期し、DTS 増分同期機能を有効にすることを選択しました。ダウンタイムウィンドウに基づいて、データベースのオンライン移行と増分同期に 4 時間かかります。 DTS サービスは、移行経験とテスト環境の評価に基づき、オンラインビジネスに影響を与えません。

サービスがシャットダウンされる前の午後、移行に十分な時間バッファを残すために、メインデータベースの DTS サービスを事前に開始しました。データベース移行プロセスは正常に進行し、推定移行時間は 4 時間でした。しかし、DTS サービスの最終段階で、ソース側の binlog の問題により致命的なエラーが発生し、DTS タスクが失敗しました。

移行タスク実行エラー

エラー 1236 (HY000): スレーブは CHANGE MASTER TO MASTER_AUTO_POSITION = 1 を使用して接続していますが、マスターはスレーブが必要とする GTID を含むバイナリログを消去しました。

地域: cn-north-1

クラスターGID: dts-r1rroa

最終的な binlog エラー (binglog の一部が失われました) のため、DTS タスクを復元できず、DTS 送信時間の最後の 4 時間が無駄になりました。移行はシステムプロジェクトであるため、他のデータ移行プロセスも計画どおりに進んでいます。現時点では、具体的な理由を分析する時間のある人は誰もいません。

夕方までに顧客業務への通知とサービス停止が済んでいたため、業務移行に向けたその他のデータ移行や業務デバッグはすでに開始されていた。

そのため、すぐにmysqldumpモードでファイルをエクスポートすることにしました。ローカルエクスポート速度は非常に高速（20M/s）で、圧縮されたデータベースエクスポートファイルのサイズが縮小されるため、ネットワーク転送時間が短縮されます。データはネットワーク経由で JD Cloud 側のクラウドホストに送信され、ソースモードで RDS にインポートされます。エクスポート、転送、インポートの全プロセスは 2 時間未満で完了します。

MySQL データをインポートした後、移行プロセスに従って移行されたデータを検証し、checksum_table ツールを使用してソースデータベースと宛先データベースを比較します。

ソースライブラリ情報: —src-host sourceIP —src-user user —src-pass pass

ターゲットライブラリ情報: —dest-host targetURL —dest-user user —dest-pass pass

検証プロセス中に、いくつかのテーブルに不一致が見つかりました。業務側に確認したところ、移行開始後にソース側でサービスが不完全に停止し、データが書き込まれたままになっていることが原因でした。これは、ビジネス側が移行仕様に従って MQ と Kafka のメッセージ生成を確認しておらず、一部のサービスのみを停止したためです。ビジネス部門と研究開発部門が新しいデータを確認し、一部のデータをクリーンアップした後、データベースの移行が完了しました。

プロジェクトの経験によれば、binlog の問題によるこの種の DTS サービス障害は孤立したケースではありません。

準備

（１）データベース移行の代替計画を準備し、緊急時対応計画を準備しておく。

（２）問題が発生した場合には、事前に意思決定条件や意思決定者を確認し、実施過程において必要に応じて適時意思決定や調整を行うことができる。

ベンダーが変更した (非ネイティブ) データベースの移行:

一部のクラウドベンダーの特定のデータベースバージョンでは、顧客のビジネスの特定の特別なニーズを満たすために、mariaDB、PG、その他のデータベースなどの標準データベース製品に対してカスタマイズされた開発が行われます。このタイプのデータベースは製造元と深く結びついています。ビジネス移行や災害復旧データの同期を行う場合、時間のシナリオに応じてカスタマイズされた移行および同期計画が作成されます。それらのほとんどは、R&D レベルからのカスタマイズされた構成と操作を必要とします。

ケース2

元のシステムが T の金融クラウド上で実行されていた金融ユーザーは、カスタマイズされた RDS サービスを使用していました。金融業界のビジネスおよびデータの災害復旧仕様により、オフサイトの災害復旧が必要でした。目標は、ビジネスレベルの災害復旧を実現し、JD Financial Cloud Platform 上で災害復旧システムを実行することでした。

T Cloud のカスタマイズされた TDSQL から JD Cloud への移行を実現するために、ソースデータベースの詳細な調査が行われました。ソースは、自動水平分割と共有ナッシングアーキテクチャを備えたカスタマイズされた分散データベースであるため、JD Cloud の DTS ツールはこのシナリオには適していません。同時に、2 つの環境では、ビジネスの災害復旧のニーズを満たすために、基本的にデータをリアルタイムで同期する必要があります。

計画を立てる

データ同期計画を策定する際には、従来の災害復旧ベンダーのソリューションも調査しました。これは、従来のベンダーの災害復旧ソリューションが主にホストレベルのデータと IO 分析またはログ分析に基づいているため、何らかの侵入型エージェントのインストールが必要となり、クラウド RDS シナリオに適応できないためです。関連ベンダーもクラウド災害復旧への移行を進めていると述べているが、成熟した製品が未だに存在せず、導入が難しい。そのため、最終的なソリューションでは、アーキテクチャの違いによって発生する問題を遮断し、データベースの異機種クラウド同期を実現するために、gtid ベースのマスター/スレーブレプリケーションソリューションを採用しました。

注: ビジネス情報や基礎業務に関連する一部のコンテンツは非表示になっています。

まず、ソース側の権限を調整します。
GRANT SELECT、RELOAD、SHOW DATABASES、EXECUTE、REPLICATION SLAVE、REPLICATION CLIENT、SHOW VIEW ON の権限。宛先: 'user'@'192.168.%'
ソースの完全な論理バックアップを作成します。
mysqldump –h xx –uusername -p –database nx_db -f —シングルトランザクション —マスターデータ=2 —ロックテーブルをスキップ > /data1/bs.dmp
エクスポートされたファイルには gtid 情報が含まれている必要があることに注意してください。
災害復旧終了のインポート:
mysql –h xx -f –uユーザー名 -p < bs.dmp
バックステージレプリケーション構成:
gtid_slave_pos='0-13381-1xxxx06' を設定します。
マスターを MASTER_HOST='sourceIP'、MASTER_USER='username'、MASTER_PASSWORD='*'、MASTER_USE_GTID='slave_pos' に変更します。
同期検証
データ検証（1）ビジネス側で書き込み操作を停止し、Tクラウド側とJDクラウド側のチェックサムテーブルtablenameを使用してキーテーブルを検証します。
（２）ビジネス側はTクラウドとJDクラウド上でコマンドを実行し、テーブルとビューの数量検証を行う。
information_schema.tablesからcount(1)を選択します。ここでtable_schema='nx_db'です。
information_schema.viewsからcount(1)を選択します。ここでtable_schema='nx_db'です。
ビジネステストでは、テストテーブルの作成、追加、削除、変更、クエリを実行して、DDL/DML が正常に複製されているかどうかを確認します。

基本的な機能検証が完了したら、ソースデータベースのマスター/スレーブ切り替えとネットワーク中断がデータベース同期に与える影響をさらに検証する必要があります。ソースデータベースのログ構成については、長時間のネットワーク中断によるログの有効期限切れがデータベース同期業務に影響することを回避するために、Binlog ローカル保持時間要件 (48 時間以上) を提案する必要があります。

データの信頼性と業務の災害復旧を確保するには、ネットワーク専用線のリアルタイム監視とアラーム設定が必要です。ネットワーク障害が発生した場合、中間専用線ネットワークの中断が災害復旧業務の可用性に影響を与えないように、アラームを時間内に受信し、できるだけ早く処理する必要があります。

POC 検証中に、ネットワークへの影響をテストするために中断テストが実施されました。中断は2時間続きました。その後の観測データも正常に同期・追従できており、実業務で起こり得るネットワーク障害の影響を許容できることを確認した。

ソースデータベースの保護

この異種クラウド災害復旧の場合、ネットワークは専用回線を介してソースクラウドと相互接続され、ソースデータベースは IP を介してアクセスされるため、アプリケーションホストが JD.com に丸ごと移行された後も、ホストはネットワークを介してソースデータベースにアクセスでき、ソースデータベースへの書き込み操作が発生する可能性があります。ソースデータベースへのアクセスをブロックするには、ホストセキュリティグループメソッドを使用してホストの外部 3306 ポートへのアクセスをブロックするか、サブネットレベルの ACL を使用して指定されたネットワークセグメント内の特定のポートへのアクセスを制限します。アプリケーション構成を調整し、データベース接続方向を変更した後、セキュリティグループエントリまたは ACL ポリシーを調整して、対応するアクセス権を解放します。

一部のデータベースのサブネット計画の問題により、ACL の使用はデータベースの同期に影響する可能性があります。したがって、この場合は、ビジネスホストに対して追加のセキュリティグループが作成され、ソースデータベースへのアクセス保護を実装するために 3306 ポートブロッキングポリシーが構成されます。業務調整が完了したら、セキュリティグループを解除し、業務データを正常に書き込むことができます。

2. ES 移行

ES はますます広く使用されるようになっています。ビジネス移行において、ES データ移行はデータ移行の重要な部分となっています。

ES 移行テクノロジーには、サービスを停止せずに移行することと、サービスを停止せずに移行することが含まれます。サービスを停止せずに移行するには、移行元と移行先のネットワークおよびサービスに対して多くの要件があります。実装にはまだ多くの制限があります。現在、サービスを停止せずに ES 移行を行うのは、グループ内の業務のみで行うのが一般的です。

通常、サービスの停止と移行の技術的なパスには、再インデックス、スナップショット、および logstash が含まれます。各方法については、公式のバージョン要件を参照し、バージョン要件を満たす移行方法を選択してください。

スナップショット方式:

スナップショットモード: ソース ES クラスターからデータスナップショットを作成し、それをターゲット ES クラスターに復元します。スナップショットを作成する前に、まずリポジトリを作成する必要があります。リポジトリには複数のスナップショットファイルを含めることができます。リポジトリは S3 と共有ファイルストレージシステムをサポートしています。自作 ES では共有ファイルストレージを使用できます (速度、コスト、その他の要素を考慮すると、これが最良の選択です)。パブリッククラウド ES サービスを使用する場合は、S3 プロトコルをサポートするオブジェクトストレージを使用することをお勧めします。

速度と効率の点では、スナップショット方式は再インデックスよりも優れています。ソース側で変更が不要で、ネットワークストレージ条件が利用可能な場合は、ES の移行にはスナップショット方式が推奨されます。

Reindex は Elasticsearch が提供する API インターフェースであり、ソース ES クラスターから現在の ES クラスターにデータをインポートしてデータ移行を実現できます。再インデックスは、データ量が多い、インデックス調整が必要である、または共有ストレージに接続できない移行シナリオや、データの一部のみを移行する必要があるシナリオに適しています。

再インデックス方式では、ターゲット側がソース ES のサービスポートにアクセスできる必要があります。

ケース3

顧客のビジネスは、フレンドリーなクラウドプロバイダーから JD Cloud に移行されました。ソース ES は、K8S クラスターの独自構築サービスでした。サービスアクセスメソッドは nodeport でした。セキュリティ上の理由により、アクセス方法は社内のビジネスホストアクセスに制限されており、サービスはインターネットを通じて外部に公開されていませんでした。

移行テクノロジーソリューションを選択します。ソース側でビルドされた ES には S3 プラグインがインストールされていません。スナップショット移行ではソース側にS3プラグインのインストールが必要であり、PODモードで展開された業務ではイメージの再作成とアプリケーションの更新が必要であることを考慮すると、時間と作業負荷の観点から最適な選択とは言えません。したがって、ビジネスデータを移行するには、再インデックスメソッドが使用されます。

JD Cloud から ES にデータをプルするために、ソース側に nginx リバースプロキシが構成され、パブリックネットワークを介して内部 ES インターフェイスにアクセスできるようになります。同時に、データアクセスのセキュリティを確保するために、アクセス IP を JD Cloud NAT ゲートウェイエクスポートのパブリック IP に制限するホワイトリストが構成されます。

JD Cloud 側では、本番環境のサブネットにパブリックネットワークの出口が設定されていないため、一時的にデータを引き出して移行要件を満たすために、ルーティングテーブルを調整し、詳細なルートを設定し、対応するサブネットのルーティングテーブルにソースエンドのパブリックネットワーク IP を設定して NAT ゲートウェイを指し示し、一時的にパブリックネットワーク接続を開きます。ソース側の ES データは NAT ゲートウェイを介して取得でき、ソース側のパブリックネットワーク IP は ES サービスでホワイトリストに登録されます。ホワイトリスト操作により ES サービスが再起動されることに注意してください。

ネットワーク通信要件を満たすために、ES サブネットの詳細なルートを一時的に構成します。データ移行が完了したら、詳細ルートを削除します。

移行前に、関連する移行条件が満たされていることを確認してください。

ソース側と JD Cloud ES サービスの両方が対応するインデックスを作成します。クラウド上のインデックスが新しく作成されたことを確認する必要があります。ソース側と宛先側のマッピングは同じでも異なっていても構いません。再インデックスを通じて、マップされたフィールドのタイプを変更できます。
JD Cloud 側の ES からソースクラウド側の ES のサービスポートにアクセスできます。確認するには、telnet または curl -XGEThttp://:9200 を使用できます。

ソース側にインデックスを作成します。

ソース ES クラスター

1. インデックスを作成する（例）

2. データの書き込み（例）

ターゲットES構成

3. オブジェクトストレージの移行

S3 プロトコルと互換性のあるオブジェクトストレージデータの移行については、すべてのパブリッククラウドベンダー (一部の従来の災害復旧ベンダーを含む) が移行ツールまたはスクリプトを用意しており、移行技術は難しくありません。ただし、異なるメーカーのオブジェクトは異なるリージョンに保存されるため、基盤となるバージョンや構成に違いが生じる可能性があります。

したがって、同じツールまたはスクリプトで、異なるリージョンのオブジェクトストレージデータを処理するときに、ファイルアクセスの問題が発生する可能性があります。移行の前後に、移行されたデータの整合性と可用性を検証する必要があります。

オブジェクトストレージ移行の一般的な手順は次のとおりです。

1. 404 読み取りエラーが発生したときにデータを取得できるように、ターゲット側でミラーリングを構成してソースに戻します。

2. 移行ツールを使用してソース側の履歴データを移行する

3. 同期後のデータ検証

実際の移行では、増分データの同期が伴うため（移行ツールは、ファイルを上書きするかどうかを決定する transfer.coverFile のパラメータ設定をサポートしているため、増分コピーも可能です）、実際のデータストレージ容量、ビジネスアクセス特性、ビジネスダウンタイムウィンドウ、およびプロジェクトのその他の情報に基づいて、移行プロセスと技術的ソリューションを総合的に検討する必要があります。

ケース4

あるビジネスは競合他社のクラウドから JD Cloud に移行され、オブジェクトストレージの移行も行われました。ソース側のファイル数は約1000万個でした。移行前に、移行ツールのリストデータがオブジェクトストレージ内の実際のデータと一致するかどうかを確認するために、ソースオブジェクトストレージのファイルリストが作成されました。次に、移行ツールを使用して移行操作を実行しました。ファイル量が多く、毎日新しいデータがビジネスにアップロードされるため、すべてのファイルが正しく同期されていることを確認する必要がありました。したがって、採用された履歴および増分データ同期ソリューションは、1 週間前に完全な移行を実行し、新しく追加されたファイルをミラーリングを通じてソースに同期することです。カットオーバーの1週間前に完全な移行を実行する

1. カットオーバーの 1 週間前に、JD Cloud の osstransfer 移行ツールを使用して完全な移行を実行します。

2. 移行後、ソース OSS バケットの名前が付けられた .list.txt ファイルが生成されます。このファイルには、ソース OSS バケット内のすべてのファイルのリストが含まれています。

3. 移行ログは、移行ツールキットのログディレクトリに生成されます。関連ログの説明（ログファイルは非常に重要であり、移行が完了した後にオフサイトバックアップが作成されます）：移行されたすべてのファイルはaudit-0.logに記録されます。

移行に成功したファイルはaudit.successに記録されます。

移行に失敗したファイルを表示するには、コマンド grep "1$"audit-0.log を使用できます。

生成されたソース OSS インベントリファイルリストの txt ファイル内のファイル数と、audit.success ファイル内のファイル数を比較します。数値が一貫している場合は、すべての移行が成功したことを意味します。

ファイルリストから構成を取得する例:

カットオーバー日に完全移行を行った後の増分移行

1. osstransfer ツールを使用して、ソース oss マニフェストファイルのリストを生成します。

2. 完全移行から増分移行までの期間中にファイルリストから新しく追加されたファイルを見つけます。

3. OSS ミラーリングを有効にします。

4. curl を使用して新しく追加されたファイルにアクセスし (ターゲット OSS にアクセス)、新しく追加されたファイルをソースにミラーリングします。

実際の移行中に発生した問題:

POC フェーズでは、このソリューションを使用して、テスト環境でデータを移行するときにすべてがスムーズに行われたことを確認しました。しかし、本番環境への切り替え中に問題が発生しました。増分ファイルの決定に必要なリストで循環エラーが発生したため、リストタスクは実行を継続し、リストには大量の重複コンテンツが含まれていました。

移行ソフトウェアのバージョンは、テスト環境での移行に使用したバージョンと一致しており、本番環境では、1週間前の移行ソフトウェアの完全同期も正常に動作していました。データは JD Cloud のオブジェクトストレージにも正常に同期されます。カットオーバー時には、新たに追加されたファイルをソースリターン方式で 1 週間以内に取得する必要があります。リストファイルが正しくない場合、増分データ同期は失敗します。

問題解決

業務の切り替え時間は限られていたため、問題はすぐにアップグレードされ、ツールソフトウェアの R&D 担当者にフィードバックされ、すぐに調査が開始されました (すでに早朝でしたが、JD の R&D 担当者のプロ意識には感服です)。 R&D の同僚による調査の結果、テスト環境で使用されていたオブジェクトストレージと、友好企業のソースクラウド上の運用環境のオブジェクトストレージが異なるゾーンに配置されていたことが判明しました。今週、友好企業のクラウドの本番環境オブジェクトストレージが配置されているゾーンの OSS インターフェースが調整され、元のツールリストにエラーが発生していました。

R&D の同僚がツールキットを緊急に更新し、移行現場の同僚に提供しました。これにより、オブジェクトストレージのファイルリストループエラーの問題が解決され、ファイルリストのチェックが正常に完了しました。前後に生成されたリストファイルを比較することで、新しく追加されたファイルリストを取得しました。ソースへのミラーリングを構成し、スクリプトを使用して 1 週間分の新しいファイルを同期し、検証後にビジネスアプリケーションを構成してオブジェクトストレージを有効にすると、ビジネスの起動と検証作業は通常どおり続行されます。

4. Redis 移行

Redis をビジネスで使用するシナリオは 2 つあります。 1 つは、データを永続化せずにキャッシュとしてのみ使用することです。このビジネスシナリオでは、移行後、新しい環境にビジネスを展開した後、新しい Redis インスタンスを指すようにビジネスを直接調整できます。もう 1 つは、データの永続性を確保することです。このビジネスをクラウドに移行する場合、ビジネスニーズに応じて Redis データを移行する必要があります。

Redis には、rdb (ポイントインタイムスナップショット) と aof という 2 つの永続化ソリューションがあります。 rdb モードはスナップショットに似たバイナリ形式であり、復元時に直接上書きされます。 aof は追加モードと同様にコマンド (テキスト形式) を保存します。ターゲットの Redis のデータを保持する必要がある場合は、aof メソッドを使用できます。 aof メソッドでは、ソース Redis が書き込みを停止する必要があります。 Redis は RDB をロードし、AOF よりも高速にデータを復元します。ただし、古いバージョンの Redis サービスは、新しいバージョンの RDB 形式と互換性がないことに注意してください。したがって、RDB モードはダウングレード移行やリカバリには適していません。

サービスを移行する場合は、Redis の使用シナリオ、ソースと宛先のバージョン要件、データストレージ、ネットワーク条件などに基づいて、適切な Redis 移行ツールを選択する必要があります。

Rdbとaofの移行については公式に詳細な手順書（bgrewriteaof/bgsave/redisdumpなど）があり、使い方も比較的簡単なので本記事では詳しく紹介しません。

JD Cloud は、Redis レプリケーションプロトコルをシミュレートして Redis の移行と同期を提供する Redis 移行ツール redissycner (現在はセルフビルドの Redis ビジネス移行をサポート) を開発しました。

Redissycner は docker 経由でデプロイされます:

git クローン https://github.com/TraceNatur...

ディレクトリに入る docker-compose up –d

クライアントソフトウェアをダウンロードします: wgethttps://github.com/TraceNatur... md64.tar.gz

設定ファイルを調整します: .config.yaml syncserver: http://xxxx:8080 (docker サービスアドレス) token: xxx

トークンファイルの内容はコンテナー内で確認する必要があることに注意してください。

設定ファイルを編集した後、実行するタスク json を記述することで、サービスを起動し、動作環境を設定できます。

 {
 「ソースパスワード」 : 「xxxx」 、
 " ソースRedisアドレス " : " 10.0.1.101:6379 " 、
 "ターゲットRedisアドレス" : " 10.0.1.102:6379 " ,
 "ターゲットパスワード" : "xxxx" 、
 「タスク名」 : 「テストタスク」 、
 "ターゲットRedisバージョン" : 4.0 、
 「自動起動」 : true 、
 「新たに」 ： 真、
 「バッチサイズ」 : 100
 } redissyncer - cli - i
 redissyncer - cli > タスク作成ソース./task .json

5. データバックアップの重要性

データのバックアップは、ビジネス移行のライフサイクル全体（移行後の期間を含む）において、強調しすぎることのないリンクです。不十分なデータバックアップによるデータ損失やビジネスへの損害については、学ぶべき教訓が数多くあります。ただし、移行の実装プロセス中に、データのバックアップを怠ることによって発生する問題は依然としてよくあります。

質問は、顧客、弊社の実装チーム、ISV、またはデータを操作する可能性のある他のチームや個人から寄せられる場合があります。いくつかの問題は、移行の責任者間のコミュニケーション不足、宣伝と実施の不十分さ、または技術の不十分さによって発生します。いくつかは誤操作によって発生します。

実際のシナリオでデータバックアップを実装する際のプレッシャーや抵抗は、主にストレージ領域の不足と、バックアッププロセスによって生じるパフォーマンスへの影響によって生じます。

バックアップされたデータファイルに必要なストレージスペースに加えて、データベースファイルの可用性と一貫性の検証にも大量のストレージスペースが (一時的に) 必要になります。したがって、実際の移行プロセスでは、ストレージスペースの需要が、既存のデータベースのデータ量の 2 倍以上になる可能性があります (ソース側とターゲット側の両方)。したがって、重要なビジネスシナリオでは、移行前に、データのバックアップに必要なストレージスペースを評価し、バックアップスペースのコストを考慮する必要があります。

ケース5

ある官庁・委員会の業務が VMware 環境から政府クラウドに移行されました。移行前に、作成者は顧客向けに移行されたすべてのホストの完全なマシンバックアップを作成しました (VMware 外部の外部ストレージにエクスポート)。事実は、これらのリンク (ストレージ環境の準備、VMware 運用保守担当者との通信、時間のかかるデータエクスポートなど) によって発生するコストの増加は価値があることを証明しています。

移行プロセスはスムーズに進みました。業務を政府クラウドに移行し、通常サービスが終了してから約1か月後、お客様から移行前にバックアップしたホストからデータを復元したいとのご連絡をいただきました。

原因

その理由は、ISV が新しい環境で業務をアップグレードする際に、経験の浅い新人にデータベースソフトウェアの再インストールと元のデータの削除を依頼したためです。顧客がバックアップ画像（履歴データと新しいデータがISVによって補足された）を復元するのを支援した後、顧客は政府クラウドが提供する災害復旧サービスを購入し、ビジネス上の誤りや誤用によって引き起こされる損失を回避または削減するために、クラウドの災害復旧サービスを使用して、重要なホストとデータの完全かつ増分バックアップを定期的に実行し始めました。