SQL Server センサーレス システムを MySQL に移行する方法

1. アーキテクチャの概要

既存システムのボトルネックの分析により、中心的な欠陥が分散した順序データ キャッシュに集中しており、それがデータの両端での不整合につながることが判明しました。各注文アプリケーションはデータベースに直接接続されているため、スケーラビリティが生じます。実践を通じて、データ アクセス層を抽象化して統合するためのミドルウェアを作成し、データベース デプロイメント アーキテクチャのミラーに基づいて注文キャッシュを構築してホット データを均一に管理し、異なるエンド間の差異を解決しました。

#図 1.1 ストレージ システム アーキテクチャ図

2. アプリケーション シナリオ

1. 各エンドの新しい 1 秒レベルの同期

注文の送信から両端での可視化までの速度は、ストレージ サービスの中核指標の 1 つです。新しい注文の同期、リアルタイムのメッセージ プッシュ、クエリ インデックスの構築をカバーする、データ チェーンの主要なリンクを最適化しました。データプラットフォームのオフラインアーカイブ 主要なリンクを待って、大規模システムでのデータ到着速度が 3 秒以内であることを確認します。つまり、ユーザーは注文後すぐに My-Carry リストにジャンプできます。

新しいユーザーが注文を作成すると、同期サービスはデータ リンクの入り口として機能し、ミドルウェアを介してユーザーの注文データを注文データベースに書き込みます。この時点で、ミドルウェアは注文キャッシュの構築を完了します。同時に;

注文が完了したとき 倉庫保管動作とホットスポット データの構築が完了した後、注文メッセージがスローされ、リアルタイムで各サブシステムに出力されます;

新しい注文が完了したとき、注文詳細の ES インデックスは、第三者に検索サポートを提供するために即座に構築されます。

最後に、データ プラットフォーム T 1 は、BI などのさまざまなオフライン ビジネスで使用するための日次データのアーカイブを実装します。

図 2.1 データ リンク

2. 自動注文発行とワークベンチ

顧客、販売者、および従業員のワークベンチのサポート注文保管システムの基本的な役割 図 2.1 のデータリンクは、新規注文が送信された後の自動注文発行とワークベンチを接続するために不可欠な役割を果たします。自動注文は、顧客が注文を送信した後、在庫を確認して注文を確認するために、できるだけ早く販売者に注文の詳細を送信するプロセスです。ワークベンチは、従業員が注文を取得し、手動イベントをタイムリーに処理するプロセスを支援します。

図 2.2 ストレージ システムに基づくオーダー発行とワークベンチの関係 (詳細は省略)

3. クエリとデータ分析

ベース受注データを核に、オンラインクエリとデータ分析の2つの事業に大きく分かれており、詳細なクエリを例に挙げると、年間を通じてアクセスQPSが高水準を維持しているほか、休日の繁忙期にはクエリが発生しやすいサブアーキテクチャのアップグレード中に、関連するシナリオで高可用性を最適化するための調整を行いました。

• オンライン クエリは主に注文キャッシュに基づいています。注文が送信されると、クエリの負荷を軽減するためにホットスポット キャッシュが構築され、設定に応じて長期間有効になります。時間パラメータ。

• 非オンライン クエリ シナリオ、Hive データ ウェアハウス T 1 と組み合わせたリアルタイム メッセージ プッシュおよび配信、長期の注文データが必要なあらゆる機会 (リアルタイム レポートなど)注文メッセージにリアルタイムでアクセスして計算できます。大規模なデータ分析を行う場合、オフラインBIではHiveテーブルを利用し、毎日早朝の低ピーク時間帯にデータベースから低頻度アクセスでデータ同期を行います。

上で述べたように、当社は注文キャッシュ、リアルタイム メッセージング、Hive データ ウェアハウスのトロイカの背後にある主要な注文データベースへのアクセスを保護し、それをビジネスから切り離しています。できるだけ。

3. システム アップグレードの実践

Ctrip のコア ストレージ システムをアップグレードするプロセスでは、プロセス全体を通じて実行する必要があるのはライブ マイグレーションであり、すべての操作はデータ リンク上で実行する必要があります。 . 各アプリケーションの目標は、透過的でロスレスであることです。グループのデータリンクの特性を総合的に分析し、オーダーキャッシュシステムによるデータベースミラーリングによりアプリケーションとデータベースの直接結合を軽減し、ミドルウェアによりSQLServer/SQLServer由来のデータ間の物理的関係を透過的に削除する設計を採用しています。 MySQL を使用し、アプリケーションに基礎となるレイヤーを提供し、ライブ マイグレーションのための操作スペースを提供します。

ロスレス移行のプロセス設計と組み合わせることで、各データベース トラフィックの可視性と制御性に重点を置き、データベース全体、シャード レベル、テーブル レベル、CRUD 操作レベルでのトラフィック分散戦略をサポートし、十分なサービスを提供します。基礎となるデータ移行のサポート、実装手段。データ ウェアハウス接続の設計は、データ プラットフォーム上の数百億のオフライン データとデュアル データベースのオンライン期間の間の同期の問題を解決すること、および MySQL へのフル アクセス中に発生するデータの問題を解決することに重点を置いています。

以下は 3 つのパートに分けて、このプロセスで学んだ経験を共有します。

1. 分散注文キャッシュ

ビジネスの発展に伴い、ユーザー数と訪問数が増加し、注文システムのアプリケーションとサーバーに対する負荷も増大しています。オーダー キャッシュが導入される前は、各アプリケーションが個別にデータベースに接続していたため、クエリされたデータをアプリケーション間で共有できず、1 秒あたりの DB クエリと接続の数に上限がありました。リンクは DB ストレージに基づいており、ポイント障害のリスクが 1 つありました。

データ分析後の注文システムは通常、読み取りが多くなり、書き込みが少なくなります。ホットクエリのデータを共有してDBの負荷を軽減するには、図3.1に示すようにキャッシュを導入するのが効果的です。ユーザーのリクエストが来ると、キャッシュが最初にクエリされ、キャッシュされたデータが存在する場合は結果が直接返され、キャッシュにヒットしなかった場合は DB がクエリされ、構成ポリシーに従って DB 結果データが検証されます。検証に合格すると、DB データはその後のクエリで使用するためにキャッシュに書き込まれ、それ以外の場合はキャッシュに書き込まれず、最後に DB クエリの結果を返します。

図 3.1 オーダー キャッシュの基本設計

新しいキャッシュ コンポーネントを導入した後のハードウェア オーバーヘッドについては、元々散在していたハードウェア リソースを集約することで削減できます。総コストがかかる一方、一元管理すると使いやすさやデータの整合性の問題も生じるため、既存システムの容量評価、トラフィック見積もり、キャッシュテーブル値の分析を十分に行う必要があります。アクセス量の多いホット データ テーブルのみをキャッシュします。適切なキャッシュ構造設計、データ圧縮、およびキャッシュ削除戦略を通じて、キャッシュ ヒット率を最大化し、キャッシュ容量、ハードウェア コスト、可用性の間で適切なトレードオフを実現できます。

従来のキャッシュ設計では、1 つのデータベース テーブル レコードが 1 つのキャッシュ データに対応します。注文システムでは、1 つの注文に対して複数のテーブルをクエリすることが非常に一般的です。従来の設計を採用すると、テーブルの数に応じてユーザー クエリ内の Redis アクセス数が増加します。この設計では、ネットワーク IO が大きく、時間がかかります。消費する、長い。テーブル ディメンションのトラフィック データを調べたところ、いくつかのテーブルが一緒にクエリされることが多く、クエリ トラフィックの 90% を超えるテーブルが 30% 未満であることがわかりました。ビジネスの観点からは、それらは同じものに分類できます。図 3.2 では、キーとして注文番号、フィールドとしてフィールド名、値としてフィールド データを使用するなど、ハッシュ構造に基づいて格納されます。

この方法では、単一テーブルであっても複数テーブルクエリであっても、各注文は Redis に 1 回アクセスするだけで済むため、キーが減り、複数テーブルクエリの数が減り、パフォーマンスが向上します。同時に、値は protostuff に基づいて圧縮されるため、Redis のストレージ容量とその後のネットワーク トラフィックのオーバーヘッドも削減されます。

図 3.2 ドメインベースのストレージ構造の簡単な説明

2. ロスレス移行プロセス

ロスレス ホット マイグレーションを実現する方法は、プロジェクト全体 最も困難な場所。事前作業としては、まずデータベース層とビジネス層のアプリケーションを分離し、プロセス設計を行えるようにするためのミドルウェアの開発を完了します。次に、抽象的な Dao 層がドメイン化を実装し、データ ドメイン層がアプリケーションにデータ サービスを提供し、そのドメインの下に SQLServer と MySQL の 2 つのデータベースが適応され、均一にパッケージ化されます。これに基づいて、次のプロセス設計に対してロスレス サーマル マイグレーションを実装できます。

• SQLServer と MySQL のデュアル データベースはオンラインであり、二重書き込み、プライマリ SQLServer 書き込み、および同期書き込みセカンダリ MySQL を実装しています。SQLServer 操作が失敗すると、操作全体が失敗し、二重書き込みトランザクションも失敗します。ロールバックされます。

• SQLServer と MySQL の間に同期ジョブを追加して、SQLServer の最新の時間枠で変更されたデータをリアルタイムでクエリし、MySQL のエントリの一貫性を確認します。差異は次のように追跡できます。これは、この期間中に双方の間で予期せぬ不一致が発生した場合、特に SQL Server アプリケーションへの直接アクセスがまだある場合に特に役立ちます。

• このミドルウェアは、あらゆるメジャー クエリ ディメンションをサポートする構成システムで設計されており、構成に従ってデータ ソースを SQLServer または MySQL に正確に送信し、それをロードするかどうかを制御できます。読み取り後に注文キャッシュに保存されます。初期設定では、2 つのデータベース間のデータの不一致によって引き起こされるキャッシュ データのジャンプを回避するために、SQLServer データ ソースのみをロードします。初期段階では、グレースケールを設定し、少数の非コア テーブルを MySQL に直接接続して検証し、信頼性を確保できます。遅延データの一貫性の期待が達成されると、指定されたデータベースに対して注文キャッシュを自由にロードできます。

• データのクエリ時にデータの整合性を確保した後、トラフィック ポリシーは、図 3.3 の制御可能なディメンションに基づいてデータベースへの単一書き込みをサポートします。実際のプロジェクトでは、シングルライトは主にテーブル ディメンションで実装されており、指定したテーブルがシングルライト MySQL で構成されている場合、そのテーブルに関係するすべての CRUD 動作はキャッシュ ロード ソースを含めて MySQL に送られます。

• 最後に、外部から送信される注文メッセージはミドルウェアを介して統合され、すべてのメッセージはミドルウェアの CUD 操作に基づいて送信され、物理データベースとは何の関係もありません。 、メッセージのデータ ソースは透過的であり、上記にリンクできます。すべてのプロセス操作とデータ リンクは一貫性を保ちます。

図 3.3 運用プロセスの概要

3. データ ウェアハウス接続

本番データからデータへの理解 ウェアハウス ODS 層データの移行は、下流ユーザーには透過的 ここでは、従来のデータ ウェアハウスの階層システムについて簡単に紹介します。通常、データ ウェアハウスは主に 5 つの層に分かれています: ODS (オリジナル データ層)、DIM (ディメンション)、EDW (エンタープライズ データ ウェアハウス)、CDM (共通モデル層)、ADM (アプリケーション モデル層)、

以下に示すように:

図 3.4 データ ウェアハウスの階層構造

図 3.4 からわかるように、データ ウェアハウスの各層は ODS 層のデータに依存しており、データ プラットフォームのすべてのアプリケーションに影響を与えないように、元の注文ライブラリを変換するだけで済みます。ODS レイヤーのデータ ソースは SQLServer から MySQL ライブラリに移行できます。

図から、移行はデータソースを変更するだけで済むことが直感的にわかります。それほど面倒ではありませんが、データ品質を確保するために、次のような多くの準備作業を行っています。 : DBA は事前に本番データを本番に同期します。MySQL データベース、MySQL データのリアルタイム同期、本番の両側でのデータ整合性検証、MySQL 側の ODS 層へのデータ同期、ODS 層のデータ整合性検証、および元の ODS 層同期ジョブデータソースの切り替えなど

その中で、本番環境の両側でのデータ整合性チェックとデータ ウェアハウスの ODS 層でのデータ整合性チェックは、最も複雑で時間がかかります。データ ソースを切り替える前に、フィールドに一貫性がある必要があります。ただし、実際の運用では完全に一致するわけではありません。時刻型、浮動小数点値の精度、小数点以下の桁数などは、実際の状況に応じて適切に処理してください。

以下はプロセス全体の概要です:

まず、オンライン データの整合性検証のために、SQLServer データと MySQL データを比較するオンライン同期ジョブを開発しました。 、不一致が見つかった場合、MySQL データは SQLServer データに基づいて更新され、両側のデータの一貫性が保証されます。

2 番目に、オフライン データの整合性検証のために、データ ウェアハウスの同僚と協力して MySQL 側のデータを ODS レイヤーに同期し (SQLServer か MySQL テーブルかを区別するためにデータベース名を使用します)、スケジュールされたタスクを組み合わせます。 SQL Server 側のタスクは、時間内で可能な限り一貫している必要があります。双方のデータが準備された後、オフライン データ検証スクリプト ジェネレーターを開発し、データ ウェアハウスのメタデータに基づいて各テーブルの同期ジョブを生成し、スケジューリング プラットフォームにデプロイしました。

同期タスクは、両側の ODS 層同期データに依存します。T1 データ同期が完了すると、一貫性チェックが実行され、一貫性のない注文番号が一貫性のない詳細テーブルに記録されます。不整合なデータ量がカウントされ、結果が統計テーブルに保存されます。次に、セルフサービス レポート プラットフォームでレポートを作成し、矛盾したテーブルの毎日の統計と矛盾の量をメールボックスに送信します。矛盾したテーブルのトラブルシューティングを毎日行って、問題を発見し、比較戦略を調整し、比較ジョブを更新します。 。一般的なプロセスは次のとおりです。

図 3.5 全体的な一貫性検証プロセス

最後に、オンライン データとオフライン データの一貫性が徐々に高まるにつれて、データODS 層ジョブに同期された元の SQLServer のソースが MySQL に切り替えられました。ここにいる学生の中には、「なぜ MySQL 側の ODS 層のテーブルを直接使用しないのですか?」という疑問を持つ人もいるかもしれません。その理由は、統計によると、元の ODS レイヤー テーブルに依存するジョブが数千個存在するためで、依存するジョブを MySQL 側の ODS テーブルに切り替えると、変更作業負荷が非常に高くなるため、元の ODS を直接切り替えます。レイヤ同期データ ソースを MySQL にインポートします。

実際の運用では、すべてのデータソースを一度にカットすることはできません。3 回のバッチに分けて実行します。最初のバッチとして、重要度の低いテーブルを十数個見つけます。カット後、2 週間実行してフィードバックを収集します。ダウンストリームデータの問題について。サンプルの最初のバッチは 2 週間後に正常に分析され、下流のレポートでデータの問題は発生しませんでした。これはサンプル データの品質の信頼性を証明しています。次に、残りの数百のテーブルを重要度に応じて 2 つのバッチに分割し、完了するまで切断を続けます。

この時点で、データ ウェアハウス層での注文データベースの SQLServer から MySQL への移行が完了しました。

4. 主要な問題のまとめ

実際、どんなに綿密な分析と設計を行ったとしても、実行プロセス中にさまざまな課題に遭遇することは避けられません。古典的な問題をいくつかまとめました。これらの大小さまざまな問題は、最終的には技術的な手段によって解決され、目標は達成されましたが、読者の皆さんには、より良い解決策があるはずです。一緒に学び、進歩できることを嬉しく思います。

1. SQLServer と MySQL のトラフィック移行をきめ細かく監視する方法

注文システムには多数のアプリケーションとテーブルが含まれており、1 つのアプリケーションは 1 ～ n 個のテーブルに対応し、1 つのテーブルに対応します1 対 n のアプリケーションは、典型的な多対多の関係に対応します。図 4.1 に示すように、ある SQLServer データベースから別の MySQL データベースに切り替える上位層アプリケーションの場合、基本プロセスは、操作プロセスの章に従って少なくとも次のステップに分割されます。 ## 単一書き込み SQLServer から二重書き込み SQLServer と MySQL になる

• 単一読み取り SQLServer から単一読み取り MySQL へ

• 二重書き込み SQLServer から MySQL へMySQL を単独で書き込むための SQLServer と MySQL の書き込み

• オフライン SQLServer

##図 4.1 アプリケーションとデータベースの関係図実稼働環境でのデータベース システムの置き換えは、高速道路で停止せずにタイヤを交換するようなもので、元の速度を維持し、ユーザーの影響を考慮しない必要があり、そうでなければ結果は想像できません。

スイッチング処理では、二重書き込み、単一読み出し、単一書き込みの各処理が段階的に連動・依存しており、それを支援する設計モニタリング手法として、前回の動作が期待通りの効果を発揮していることを事前に確認する必要があります。次へ進みます。きれいに切り替えることなく、軽率に次のステップをスキップしたり次のステップに進んだりすると、たとえば、二重書き込みが完全に整合する前に MySQL データの読み取りを開始すると、データが見つからないか、ダーティなデータが見つかる可能性があります。次に、各 CRUD 操作の読み取りと書き込みを監視し、移行プロセス中に死角のない 360 度の視覚的なトラフィック セグメンテーション制御を実現する必要があります。具体的な方法は次のとおりです:

• すべてのアプリケーションがミドルウェアに接続され、構成に従ってどの DB のどのテーブルを読み書きするかはミドルウェアによって CRUD が制御されます。

• #各読み取りおよび書き込み操作の詳細情報は ES に書き込まれ、Kibana および Grafana 上で視覚的に表示され、DBTrace を通じて各 SQL がどの DB で実行されたかを知ることができます。
  # #アプリケーション レベルに従って二重書き込み DB を段階的に構成し、同期ジョブを通じてリアルタイムで両側の DB の差異を比較、修復、記録し、二重書き込みの最終的な不整合を検証します。オフライン T 1 による書き込みなど、二重書き込みの一貫性が保たれるまで繰り返します。

• 二重書き込みの一貫性が確保されたら、SQLServer の読み取りから MySQL の読み取りに徐々に切り替えます。ES モニタリングと DBTrace を通じて, SQLServer の読み取りがまったくないことが確認されています。これは、MySQL の 1 回の読み取りが完了したことを意味します。主キーの自動インクリメントの状況を考慮して、テーブル ディメンションを使用し、すべてのテーブルが読み込まれるまでバッチで SQL Server に書き込みます。 MySQL のみに書き込まれます。

• 要約すると、基本的なソリューションは、接続されているすべてのアプリケーションのパイプラインとして機能するミドルウェアを使用し、アプリケーション層の動作をリアルタイムで表示することでトラフィック分布を観察し、これを企業データベースと組み合わせる Trace の視覚化ツールは、アプリケーションのトラフィック スイッチング動作が実際の QPS およびデータベースの負荷変動と一致していることを検証して、移行タスクを監視します。

2. 二重書き込み時の DB 整合性問題の解決方法

ホテルの注文データベースには約 20 年の歴史があり、長年にわたって蓄積されており、複数の企業から直接的または間接的に信頼されています。部門間およびホテル内のチーム間での連携 データベース SQLServer を注文します。MySQL に切り替えたい場合は、まず二重書き込み DB の整合性の問題を解決する必要があります。不整合は主に次の 2 点に反映されます:

When Dual-write, Only SQLServer is 実際に書き込まれます , MySQL への書き込みが失敗します;

• SQLServer と MySQL への二重書き込みは成功します。同時実行、信頼性の低いネットワーク、GC、などが発生した場合、MySQL データが SQLServer と不整合になる可能性があります。

• 二重書き込みデータの整合性の保証については、同期ジョブを使用して SQL Server データを調整し、両側の DB データを取得して最終更新時刻に基づいて比較します。一貫性がない場合は、MySQL データを修復し、その後の根本原因のトラブルシューティングのために、一貫性のない情報を ES に書き込みます。

しかし、MySQL データを操作するための追加ジョブの導入により、新たな問題も発生しました。つまり、複数のテーブルが二重に書き込まれている場合、時間が 2 倍になるため、ジョブは SQLServer がデータは存在しますが、MySQL には存在しません。二重書き込みエラーを引き起こす MySQL データが直ちに修正されました。したがって、二重書き込み部分に障害が発生した場合にはフェイルオーバー機構が追加され、メッセージをスローすることで、両側の DB データが完全に一致するまで、新たな比較および修復作業がトリガーされます。

同期されたジョブおよびフェイルオーバー メッセージ メカニズムにより、データの一貫性を最終的に保つことができますが、結局のところ、第 2 レベルの間隔があり、両側のデータは一貫性がありません。また、多くのアプリケーションのさまざまなシナリオでは、欠落や単一書き込みが発生することは避けられません。 CUD 操作が SQLServer にのみ書き込まれ、MySQL には書き込まれないと判断できないため、MySQL へのこれらの書き込みミスは DBTrace では検出できません。では、MySQL が見つからないシナリオを事前に見つける方法はあるのでしょうか? 私たちが見つけたことが 1 つあります。それは、データベース接続文字列を変更し、ミドルウェアに接続されているアプリケーションに新しい接続文字列を使用し、その後すべてを見つけることです。 SQLServer の SQL は、MySQL を見逃したトラフィックを正確に特定できます。

最終的に、二重書き込み DB の不整合率は 2/100,000 からほぼ 0 まで徐々に減少しました。なぜほぼゼロなのかというと、DB の特性の違いにより、当然データの不整合が発生するからです。詳細については後続のコンテンツで説明します。

3. オーダー キャッシュの導入によって引き起こされるデータの非同期問題の処理

キャッシュの導入後は、キャッシュの書き込みまたは更新が必要になります。業界での一般的な慣行は次のとおりです。次のカテゴリに分類されます:

最初に DB に書き込み、その後キャッシュ

• 最初にキャッシュに書き込み、次に DB に書き込みます

• 最初のキャッシュを削除してから DB を書き込みます

• 最初に DB を書き込んでからキャッシュを削除します

• 利点と利点を比較する必要はなくなりました。さまざまな方法の欠点があるため、特定の実装では二重削除キャッシュまたは遅延二重削除キャッシュが使用される可能性があります。最初に DB に書き込んでからキャッシュを削除するスキームを採用しています。データに敏感なテーブルの場合は、遅延二重削除が実行されます。バックグラウンド同期ジョブは、データベース データと Redis データの間の差異を定期的に比較、修復し、記録します。設計では最終的なパフォーマンスの一貫性を確保できましたが、初期段階では依然として多くのデータの不整合がありました。主に次の側面に反映されます:

アプリケーションがミドルウェアに接続されておらず、DB 上で CUD 操作を実行した後、キャッシュが削除されないシナリオがあります。

• DB への書き込み後のキャッシュ削除の遅延により、信頼性の低いネットワークや GC などのダーティなキャッシュ データが読み取られ、キャッシュ削除の遅延が発生します。

• DB への書き込み後にキャッシュを削除しないと読み取りが行われる Redis のマスター/スレーブ切り替え中など、ダーティ データのキャッシュは読み取りのみ可能ですが、書き込みはできません。

キャッシュの一貫性の問題を解決するために、図 4.2 に示すように、元のキャッシュと DB に基づいたオプティミスティック ロックと CUD 構築マーカーを追加して、同時実行時のデータの同時ロードを制限しました。キャッシュが互いに上書きし合う動作、および現在チェックされているデータに対して CUD 操作が実行されているという認識。楽観的ロックに基づく最終ライター勝利メカニズムを使用すると、クエリ トラフィックを実現して DB に直接接続し、これら 2 つのシナリオが終了しない場合の競合問題を解決できます。最終的に、キャッシュの不整合率は 100 万分の 2 から 1,000 万分の 3 に制御されました。

図 4.2 キャッシュ整合性ソリューション

図 4.2 クエリがキャッシュを欠落している場合、または現在データにオプティミスティック ロックまたは構築マークがある場合、直結DBに問い合わせを行い、該当トランザクションが完了するまでキャッシュデータの自動ロード機能を解除します。

4. 既存の注文データを一度に調整する方法

プロジェクトの開始時に、MySQL 用に過去 N 年間のデータを一度だけ準備しました。二重書き込み段階では調整できない次の問題があります。 2 つのシナリオのデータ:

• 製造オーダー データベースは、ほぼ N 年間のデータを保持するように事前設定されているため、責任のあるジョブは、 MySQL がミドルウェアに接続される前にバックアップが N 年間存在していたので、このデータのバッチをポリシーで上書きしてクリアすることはできません。

• すべてのアプリケーションをミドルウェアに接続するには時間がかかります。ミドルウェアを二重書きする前にデータが不整合になる可能性があります。すべてのミドルウェアを適用して二重書き込みする必要があります。以前のデータを書き換える前に、すべてのテーブルを一度に修復します。

最初の点に対応して、MySQL データ クリーニング ジョブを開発しました。注文データベースには複数のシャードがあるため、コア スレッドの総数はジョブ内で内部的に設定されます。実際のシャード数。各スレッドは、対応するシャード内の指定されたテーブルのクリーニングを個別に担当し、複数のサーバーを並行して実行してクリーニングのタスクを分散します。速度制御により、運用データベースの負荷に影響を与えることなく効率が確保されます。

2 番目の点に関しては、すべてのアプリケーション インターフェイス ミドルウェアとすべてのテーブルが二重に書き込まれた後、オンライン同期ジョブ スキャンの開始タイムスタンプを調整することで既存の注文データを修復できます。修復するときは、大量のデータがロードされて注文データベース サーバーの CPU が高くなりすぎることを防ぐために、スキャンされたデータを期間に応じてスライスで処理する必要があることに特別な注意を払う必要があります。

5. データベース機能のいくつかの違い

巨大なシステムでデータベースのライブ マイグレーションを実行したい場合、さまざまなデータベース間の類似点と相違点を深く理解する必要があります。効果的に問題を解決します。 MySQL と SQL Server はどちらも一般的なリレーショナル データベースであり、どちらも標準化された SQL クエリをサポートしていますが、詳細にはまだいくつかの違いがあります。移行中に直面する問題を詳しく見てみましょう。

1) 自動増分キーの問題

自動増分シリアル番号の不一致によるデータ修復のさらに大きなリスクを回避するには、次の 2 つの点を確認する必要があります。データベースは同じ自動増分シリアル番号を共有します。したがって、それぞれが自動インクリメント操作を実行できるようにすべきではありません。したがって、データが二重に書き込まれるときは、SQLServer によって生成された自動インクリメント ID を MySQL 自動インクリメント列に書き戻します。データが MySQL のみに書き込まれるときは、MySQL を使用して自動インクリメント ID 値が直接生成されます。

2) 日付の精度の問題

二重書き込み後のデータの一貫性を確保するには、両側のデータの一貫性をチェックする必要があります。タイプは Date、DateTime、タイムスタンプ フィールドの格納精度が一貫していないため、比較中に特別な処理が必要となり、データは比較のために数秒単位でインターセプトされます。

3) XML フィールドの問題

SQL Server は XML データ型をサポートしていますが、MySQL 5.7 は XML 型をサポートしていません。代わりに varchar(4000) を使用した後、MySQL データの書き込みが失敗するケースが発生しましたが、同期ジョブは SQLServer データを MySQL に正常に書き戻すことができました。分析後、プログラムは書き込み時に非圧縮の XML 文字列を書き込みます。SQLServer XML タイプはそれを自動的に圧縮して保存しますが、MySQL はそうではありません。その結果、4000 を超える長さの書き込み操作は失敗し、SQLServer 圧縮後の長さはは 4000 未満であり、MySQL に正常に書き戻すことができます。このため、書き込み前に圧縮して長さを検証する、重要でないフィールドを保存する前にインターセプトする、重要なフィールドの保存構造を最適化する、またはフィールドの種類を変更するなどの対策を提案します。

次に、移行プロセス中に注意すべき一般的な点をいくつか示します。

5. 早期警告の実践

当社の早期警告の実践は、プロジェクトの進行中の要件の監視に限定されません。データ書き込みの異常、プロジェクト完了時の二重書き込みデータの一貫性率のレビュー、注文ライブラリの各シャードの注文書き込み量の通常の傾向をリアルタイムで監視して早期に警告する方法、および定期的に警告する方法システム全体の高可用性の受け入れ/検証については、次のページで説明します。

1. 数百億のデータ差異検証に関する警告

SQLServer から MySQL データベースへの注文データ移行の要件を満たすには、データ品質が移行の必須条件です。移行では、合理的な検証計画を設計することが移行の進行状況に関係します。データ検証については、オンラインとオフラインの 2 つのタイプに分けられます。

• オンライン データ検証と早期警告

移行中、ジョブを同期し、一貫性のないデータを計算し、一貫性のないテーブルとフィールドを ElasticSearch に書き込み、次に Kibana を使用して一貫性のないデータの量と割合を監視するダッシュボードを作成しました。監視ダッシュボードを使用して、データの不整合が大きいテーブルをリアルタイムで監視し、DBA ツールを使用してテーブル名に基づいてテーブルに対して CUD 操作を実行したアプリケーションを特定し、アプリケーションをさらに特定できます。ミドルウェアが欠落しているコード。

実際の運用では、ミドルウェアに接続されていないアプリケーションを多数発見し、変更することができました。ミドルウェアに接続されるアプリケーションが増えるにつれて、データの整合性は徐々に向上していきます。監視ダッシュボードより見られる不一致の量も徐々に減少しています。しかし、一貫性がゼロになることはなく、その原因はアプリケーションと同期ジョブの同時実行によって引き起こされ、これが最も厄介な問題でもあります。

おそらく学生の中には、二重書き込みになるのだから同期ジョブをやめればよいのではないかと疑問に思う人もいるかもしれません。その理由は、SQL Server が主な書き込み方法であり、ミドルウェアがカバーする CUD 範囲がベンチマークとして使用されるためであり、MySQL へのデータ書き込みが 100% 成功することを保証しないことに加えて、データの量が2 つのデータベースは同等であるため、一貫したジョブが必要です。データを完全に一貫させることはできませんが、同時処理により不整合をさらに減らすことができます。

私たちのアプローチは、整合性ジョブを比較するときに 5 秒の安定ラインを設定することです (つまり、現在時刻から 5 秒以内のデータは不安定なデータとみなされます)。安定線の外側を比較する場合は、注文データが安定線内にあるかどうかを再計算し、全てのデータが安定線の外側にあることが確認できた場合に比較演算を行います。比較は中止され、次のスケジュールのテストで一貫性校正が実行されます。

• #オフライン データの検証と早期警告

注文データベースの移行には、数百のテーブルと大量のオフライン データが含まれます。わずか 1 年間で注文関連データの量は数十億に達し、オフライン データ検査に大きな課題をもたらします。各テーブルの比較スクリプトを生成し、それをスケジューリング プラットフォームにデプロイするデータ整合性スクリプト ジェネレーターを作成しました。比較スクリプトは、アップストリーム SQLServer と MySQL の両側の同期ジョブに依存します。アップストリーム ジョブの実行後、データは不整合データを比較する自動照合を行い、詳細表に注文番号を書き込み、詳細表を基に不整合量を計算し、日報として発行します。毎日チェックして解決します。

通常、比較スクリプトの問題の修正やオフライン データの品質のチェックなど、不一致のトラブルシューティングと解決を継続的に行っています。オフライン データの各テーブルの各フィールドの検証は非常に複雑です。比較のために UDF 関数を作成します。UDF 関数の関数も非常に単純です。各テーブルの非主キー フィールドを結合して、新しいフィールド。両側のテーブル完全外部結合を実行する場合、等しい主キーまたは論理主キーを持つレコードも新しいフィールドを生成する必要があります。それらが異なる限り、それらは矛盾したデータとみなされます。ここでは、日付フィールドのインターセプト、データの精度、および末尾にゼロを含む小数の処理に注意を払う必要があります。

3 か月以上の懸命な作業の結果、ミドルウェアに接続されていないすべてのアプリケーションを特定し、そのすべての CUD 操作をミドルウェアに接続しました。二重書き込みを有効にした後、オンラインとオフラインの一貫性が保たれました。データは徐々に改善され、データ移行の目標に達しました。

2. ALL Shard のリアルタイム総注文量監視

どの企業も注文量監視には欠かせません Ctrip には統合早期警戒プラットフォーム Sitemon があり、主にホテルを含むさまざまな注文アラームを監視しています、航空券、無線、高速鉄道、休暇。オンライン/オフライン、国内/海外、決済方法に応じた独自の検索・表示機能や、あらゆる注文に対するアラート機能を備えています。

SQL Server から MySQL への注文データの移行中に、注文データベースに依存する 200 近くの早期警告戦略を整理しました。監視を担当する関連同僚は、 SQL Server データ ソースと MySQL データ ソースに接続されています。データ ソースとして MySQL を使用するすべての監視アラームが追加された後、アラーム戦略を有効にします。注文量が異常になると、NOC は 2 つの通知を受け取ります。1 つは SQLServer データ アラームから、もう 1 つは MySQL アラームからです。両方の側が一貫している場合、それはグレースケール検証に合格したことを意味します。それ以外の場合は失敗し、MySQL 監視の問題を調査する必要があります。

一定期間のグレースケール検証の後、両側のアラーム データは一貫しています。SQLServer データ テーブルがオフラインになると (つまり、MySQL データが単独で書き込まれる)、SQLServer をデータ ソースとして使用する早期警告戦略が実行されます。も時間が経つとオフラインになります。

3.「流浪の地球」実践運用

システムのセキュリティを確保し、緊急事態への対応能力を向上させるために、必要な訓練やストレステストを実施する必要があります。この目的を達成するために、私たちは完全な緊急計画を策定し、定期的に緊急訓練「放浪する地球」を開催しています。訓練項目には、コア/非コア アプリケーション サーキット ブレーカー、DB サーキット ブレーカー、Redis サーキット ブレーカー、コア ファイアウォール、スイッチの緊急スイッチングなどが含まれます。

キャッシュを例に挙げると、キャッシュ サービスの高可用性を確保するために、訓練中に一部のノードまたはマシンをオフラインにするか、さらには Redis サービス全体を遮断して、キャッシュなだれ、キャッシュの故障、およびキャッシュの破壊をシミュレートします。他のシナリオ。計画によれば、融合する前に、まずアプリケーションのRedisアクセスを遮断し、段階的にRedisの負荷を軽減した上でRedisを融合し、Redisなしで各アプリケーションシステムが正常に動作するかテストする予定だという。

初回の訓練では、Redis の接続が切断された際にアプリケーションエラーが急増したため、思い切って訓練を中止し、問題の原因を調査しながらロールバックしました。一部のアプリケーションの Redis 動作は統一的に管理されておらず、ミドルウェアによって制御されていないため、Redis が壊れると、アプリケーションはすぐに異常になります。この状況に対し、エラー報告アプリケーションのオーダーキャッシュアクセスポートを解析してミドルウェアに接続するとともに、ミドルウェアとRedis間の弱い依存関係を強化し、Redis操作のワンクリック切断をサポートし、さまざまなメトリクスの監視が改善されました。 2 回目の訓練では、Redis サーキット ブレーカーが成功し、すべてのビジネス システムが MySQL への完全なトラフィック アクセスで正常に実行されました。最新の Wandering Earth 演習では、コンピュータ ルームのネットワーク ブロッキングや非コア アプリケーションのブロッキングなどの一連のフォールト インジェクションの後、私たちのシステムは期待どおりの非常に良好な結果を達成しました。

このようにして、訓練に次ぐ訓練で問題を発見し、経験を要約し、システムを最適化し、緊急時計画を改善し、突然の障害に対処するシステムの能力を段階的に向上させ、ビジネスの継続性とデータの整合性を確保しました。 . セックス。ホテルの注文システム全体を保護するための基礎となるデータ サポートを提供します。

6. 今後の計画

1. 注文キャッシュ手動コントロール デスク

当社には、サーキット ブレーカー訓練、自動障害などの完全な監視ボードと早期警告システムがありますが、訓練、ハードウェアの障害とメンテナンス、および事前に予測できない問題が発生した場合、コア開発者が現場での操作に時間内に対応できなかった場合、システムは完全に自律的に機能を低下させることができず、応答時間の増加などのパフォーマンスの低下につながる可能性があります。 、など。将来的には、手動制御ダッシュボードを追加する予定です。認可後、NOC または TS に対象操作の実行を許可できます。たとえば、Redis クラスターの全体または一部がダウンした場合、障害のある Redis シャードをワンクリックで切断できます、または Redis の計画停止期間に基づいて、事前に切断時間を設定することで、システムの制御性を最大限に確保できます。

2. ミドルウェアの自動ダウングレード

手動制御が可能なため、将来的には一部のコア指標の監視も検討します。第 2 レベルでは、ただし、一部の Redis が 10 秒以上書き込めないという状況も経験しました。このとき、キャッシュとデータベースの間で矛盾するダーティ データの量を監視できます。また、適用することもできます。 Redis に障害が発生した場合に異常な応答時間のしきい値を監視することで、ミドルウェアが自動的にこれらの障害のあるホストをダウングレードして切断し、サービスの基本的な安定性を確保し、クラスター インジケーターが安定していることを検出した後、徐々に回復を試みるいくつかの戦略があります。

3. サービス メッシュへのミドルウェア アクセス

現在の発注チームは、JAR 形式のミドルウェアを使用しています。このミドルウェアは、データベース内の根本的な違いを保護し、より複雑な機能を実現するために Redis を操作します。当然、サービス メッシュにアクセスする機能が備わっています。アクセス後は、基盤となるアップグレードが高速化され、煩わしさが軽減され、呼び出しが軽くなり、フレームワークとのグリッドの統合が向上し、クラウドがより便利になり、より適切なサポートが可能になります。 Ctrip の国際化戦略、目標。

以上がSQL Server センサーレス システムを MySQL に移行する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。