背景

興業の『西遊記』には、次のような非常に有名なセリフがあります。「目の前の関係を大切にせず、それを失ったとき後悔しました。世界で最もつらいことは、これです。神が私にもう一度チャンスを与えてくれるなら、私はどんな女の子にも三言言います。愛しています。もし私が持っているなら」この愛にタイムリミットを付けて、一万年であってほしい！」開発者の目には、この感情はデータベースのデータと同じです。一万年続いてほしいと願っています。会社が発展し続け、ビジネスが変化し続けるにつれて、データに対する要件も常に変化しています。次のような状況が考えられます:

サブデータベースとサブデータベース-table: ビジネス開発がますます高速化しているため、単一マシンのデータベースへの負担がますます大きくなり、データ量も増加しています。現時点では、通常、サブデータベース手法を使用して問題を解決しています。この問題により、データベースはトラフィックが異なるマシンに均等に分散されます。スタンドアロンデータベースからサブデータベースへのプロセスでは、サブデータベースでデータを正常に使用できるように、データを完全に移行する必要があります。
ストレージメディアを交換する : 一般に、上で紹介したサブデータベースを移行した後も、ストレージメディアは同じままです。たとえば、スタンドアロンの Mysql を使用した場合、サブデータベースの移行前、移行後は、複数のマシン上で MySQL になり、データベーステーブルのフィールドは変更されていません。移行は比較的簡単です。サブデータベースとテーブルではすべての問題を解決できない場合があります。多くの複雑なクエリが必要な場合、現時点では Mysql の使用は信頼できる解決策ではない可能性があります。その場合は、elasticsearch を使用するなど、クエリの記憶媒体を交換する必要があります。これは移行のタイプは少し複雑で、さまざまなストレージメディアからのデータ変換が含まれます。
新システムへの切り替え: 一般に、企業が高速で開発を進めていると、スピードを上げるために何度も構築を繰り返すプロジェクトが多くなります。一定の期間を経て、これらのプロジェクトは統合され、一部の会員システムや電子商取引システムなどのプラットフォームまたはミドルプラットフォームになることがよくあります。このとき、よく問題に直面します。古いシステムのデータを新しいシステムに移行する必要があります。今回はさらに複雑になります。記憶媒体が変更されただけでなく、プロジェクトの言語も変更された可能性があります。上層部から見方を変えると、部門が異なるため、この種のデータ移行はより困難であり、リスクも大きくなります。

実際の事業開発では、状況に応じて移行計画を立てていきますが、次にデータの移行方法について説明します。

データ移行

データ移行は一夜にして完了するものではありません。各データ移行には長い時間がかかり、1 週間または数か月かかる場合があります。一般的に、データを移行します。プロセスは基本的に次のとおりです。下の写真: ' まず、データベース内の既存のデータをバッチ移行する必要があります。次に、新しいデータを処理する必要があります。元のデータベースを書き込んだ後、データのこの部分を新しいストレージにリアルタイムで書き込む必要があります。プロセス中にデータを継続的に検証します。基本的な問題が深刻でないことを確認したら、ストリームの切断操作を実行します。ストリームが完全に切断された後は、データ検証と増分データ移行を実行する必要はなくなります。

株式データの移行

まず、株式データの移行方法について説明します。オープンソースコミュニティで株式データの移行を検索したところ、簡単に実行できる方法は存在しないことがわかりました。現在、Alibaba The Cloud の DTS は既存のデータ移行を提供しており、DTS は同種データソースと異種データソース間の移行をサポートしており、基本的に Mysql、Orcale、SQL Server などの業界で一般的なデータベースをサポートしています。 DTS は、前に説明した最初の 2 つのシナリオに適しています。1 つはサブデータベースのシナリオです。Alibaba Cloud の DRDS を使用している場合は、DTS を通じてデータを DRDS に直接移行できます。もう 1 つは異種データのシナリオです。 Redis、ES、DTS のいずれであっても、すべて直接移行をサポートしています。

それでは、DTS ストックを移行するにはどうすればよいでしょうか?実際、これは比較的単純で、おそらく次の手順で構成されます。

セグメントを設定します。たとえば、10,000、ID の小さいものから順に 10,000 件のデータを毎回クエリし、DTS サーバーに送信して処理します。 SQL は次のとおりです:

select * from table_name where id > curId and id < curId + 10000;复制代码

ログイン後にコピー

3. ID が maxId 以上の場合、既存のデータ移行タスクは終了します

もちろん、実際の移行プロセスでは Alibaba Cloud を使用しない可能性があります。または 3 番目のシナリオでは、データベースフィールド間で多くの変換を行う必要があり、DTS がそれをサポートしていない場合、DTS のアプローチを模倣できます。セグメント内のバッチでデータを読み取ることでデータを移行します。ここで注意する必要があるのは、データをバッチで移行する場合、オンライン操作の通常の動作に影響を与えないようにセグメントのサイズと頻度を制御する必要があるということです。

増分データ移行

既存データの移行ソリューションは比較的限られていますが、増分データ移行方法が全盛です。一般的に、次の方法があります。

DTS: Alibaba Cloud の DTS はワンストップサービスと考えられており、ストックデータの移行だけでなく、増分データの移行も提供しますが、量に応じて課金される必要があります。
サービス二重書き込み: システムを切り替えずに移行する場合に適しています。つまり、サブデータベースやテーブル、Redis データの同期など、ストレージのみが変更され、システムは同じままです。この方法は比較的シンプルで簡単です。移行する必要があるデータはコード内で同期的に書き込まれますが、同じデータベースではないため、トランザクションが保証されず、データ移行時にデータ損失が発生する可能性があります。このプロセスは次のようになります。その後のデータ検証により解決されました。
MQ 非同期書き込み: これはすべてのシナリオに適用できます。データが変更されると、MQ メッセージが送信され、コンシューマーはメッセージの受信後にデータを更新します。これは上記の二重書き込みに似ていますが、データベース操作が MQ 非同期に変更されるため、問題が発生する可能性ははるかに低くなります。
監視バイナリ: 前述のカナルまたはその他のオープンを使用できます。データバスなどのソースはバイナリログ監視を行いますが、バイナリログ監視の方法は上記メッセージ MQ の方法と同様ですが、メッセージの送信手順が省略されています。この方法での開発量は基本的に最小限です。

非常に多くの方法があるため、どれを使用すればよいでしょうか?個人的にはbinlogを監視する方法がおすすめです binlogを監視することで開発コストが削減されますコンシューマロジックを実装するだけでデータの整合性が確保できます監視されたbinlogなので以前の二重書き込みの心配がありませんビジネス上の問題。

データ検証

上記のすべてのソリューションは、その多くが成熟したクラウドサービス (dts) またはミドルウェア (canal) ですが、ある程度のデータ損失を引き起こす可能性があります。データ損失は全体的に比較的まれですが、しかし、トラブルシューティングは非常に難しく、dts または canal が誤って揺れたり、データ受信時に誤ってデータが失われた可能性があります。移行プロセス中にデータが失われるのを防ぐ方法はないため、他の方法でデータを修正する必要があります。

一般的に、データを移行するときはデータ検証のステップが必要ですが、チームごとに異なるデータ検証ソリューションを選択する場合があります。

前に、美団では、いつ、二重読み取りを行います。つまり、すべての読み取りは新しいコピーからコピーを読み取りますが、返されたものは依然として古いものです。現時点では、データのこの部分を検証する必要があります。問題がある場合は、手動修理または自動修理のためにアラームを送信することができます。もちろん、完全なデータチェックも随時実行しますが、この種のチェックがデータを修復するまでの時間は比較的遅れています。
元札島以降、以前の方法は採用していません。二重読み取りチェックによりデータ内のエラーをすぐに見つけることができますが、データのこの部分をリアルタイムで修正する高度なレベルが備わっていないためです。検証や二重読み取りのためのコード開発量はまだ比較的多いですが、時々完全なチェックを行うだけでは保証できず、データ検証時間が非常に長くなる原因となります。妥協案を採用しました調停ではT1さんのアイデアを拝借し、毎朝、旧データベースから昨日更新されたデータを取得し、新しいデータベースのデータと逐一比較しました。データが異なっていたり欠落していたりした場合は、すぐに修復できます。

もちろん、実際の開発プロセスでは次の点にも注意する必要があります。

データ検証作業の正しさをどうやって保証するか? 検証作業は本来、他のデータを修正するものですが、それ自体に問題があれば検証の意味がなくなってしまいます。コードをレビューして、検証タスクが正確であることを確認してください。
タスクを検証するときは、ログの出力に注意する必要があります。場合によっては、すべてのデータの直接的な問題によって問題が発生することがあります。その場合、検証タスクによって大量のエラーログが出力され、アラームが発生することがあります。、システムがハングしたり、他の人のサービスに影響を与えたりする可能性があります。ここで簡単にしたい場合は、手動で処理されていないアラームを警告に変えることができます。より複雑にしたい場合は、ツールをカプセル化することができます。一定期間内に特定のエラー出力が一定量を超えた場合に、再度印刷する必要はありません。
検証タスクのオンライン実行サービスに影響を与えないように注意してください。通常、検証タスクは多くのバッチクエリステートメントを作成し、バッチテーブルスキャンが発生します。コードが適切に記述されていないと、簡単に悪影響を及ぼしてしまう可能性があります。データベースがハングする原因となります。

ストリーム切断

データ検証に基本的にエラーがない場合、移行プログラムが比較的安定していることを意味し、新しいデータを直接使用できますか?もちろんそんなことはあり得ません、一斉に切り替えるとうまくいけばいいのですが、何か問題が起きれば全ユーザーに影響が出てしまいます。

したがって、次にグレースケールを実行する必要があります。これはストリームの切断です。異なるビジネスフローカットのディメンションは異なります。ユーザーディメンションフローカットの場合、通常は userId のモジュロ方式を使用してフローをカットします。テナントまたはマーチャントディメンションビジネスの場合は、テナント ID のモジュロを取る必要があります。カット方法流れ。このトラフィック削減には、どの時間帯にどれだけのトラフィックを解放するか、トラフィック削減計画を立てる必要があり、トラフィックを削減するときは、トラフィックが比較的少ない時間帯を選択する必要があります。ログを詳細に観察し、問題をできるだけ早く修正しますトラフィックを解放するプロセスは、低速から高速へのプロセスです。たとえば、最初は 1% で継続的に重畳します。その後、10 を直接使用します。 % または 20% ですぐに音量を上げます。なぜなら、問題があったとしても、トラフィックが少ないときに発見されることが多く、トラフィックが少ない状態で問題がなければ、すぐにボリュームを増やすことができるからです。

主キー ID に注意してください

データの移行プロセスでは、主キー ID に特別な注意を払う必要があります。上記の二重書き込みソリューションでは、次のことも述べられています。主キーIDを手動で二重書きする必要がある ID生成順序エラーを防ぐために指定します。

サブデータベースとテーブルが原因で移行する場合は、将来の主キー ID を自動インクリメント ID にすることはできないことを考慮する必要があり、分散 ID を使用する必要があります。ここでより推奨されるのは次のとおりです。 Meituan のオープンソースリーフです。2 つのモードをサポートしています。1 つはスノーフレークアルゴリズムが増加傾向にありますが、すべての ID は Long 型であり、ID として Long をサポートする一部のアプリケーションに適しています。設定した基本 ID に基づいて上から増加し続ける数値セグメントモードもあります。そして基本的にすべてメモリ生成を使用し、パフォーマンスも非常に高速です。

もちろん、システムを移行する必要がある状況はまだありますが、以前のシステムの主キー ID が新しいシステムにすでに存在しているため、ID をマッピングする必要があります。システムを移行する際に、将来どのシステムを移行するかがわかっている場合、たとえば、システムAの現在のデータが1億から1億で、システムBのデータも1億である場合、予約方式を使用できます。ここで、2 つのシステム A と B を新しいシステムにマージする必要があります。その後、バッファーをわずかに見積もることができます。たとえば、システム A に 1 億から 1 億 5,000 万を残し、A をマッピングする必要がないようにします。、システム B は 1 億 5,000 万から 3 億です。その後、古いシステム ID に変換すると、1 億 5,000 万を引く必要があります。最終的に、新しいシステムの新しい ID は 3 億から増加します。しかし、システム内に計画された予約セグメントがない場合はどうなるでしょうか?これは次の 2 つの方法で行うことができます:

新しいテーブルを追加し、古いシステムの ID と新しいシステムの ID の間のマッピングレコードを作成する必要があります。一般的な移行には数十から数百がかかるため、このワークロードは依然として比較的大きいですテーブルとレコードのコストは依然として非常に高いです。
ID が Long 型の場合、long が 64 ビットであるという事実をうまく利用できます。ルールを定式化できます。新しいシステムの ID は、次のような比較的大きな数から始まります。 Int よりも大きいです。カウントから始めて、小さな Int の部分は、ID の移行のために古いシステムに任せることができます。たとえば、私たちの上にある 1 億 5,000 万のデータ量は、実際には 28 ビットしか使用しません。私たちの Int は 32 ビットなので、それでも 4 ビットを使用でき、これらの 4 ビットは移行対象の 16 システムを表すことができます。もちろん、計画内に移行するシステムがさらにある場合は、新しいシステムの ID 開始点をより大きく設定できます。次の図に示すように:

概要

最後に、このルーチンを簡単にまとめましょう。実際には 4 つのステップです。注意すべき点は、ストック、増分、検証、およびカット. ストリーム、最後にIDに注目してください。どんなにデータ量が多くても、基本的にはこの手順で移行すれば大きな問題はありません。この記事が今後のデータ移行作業に役立つことを願っています。