技術共有|MySQLマルチソースコピーシーン分析

作者:楊涛
今日、お客様から質問がありました.MySQLデータを1台にまとめるにはどうすればいいですか.MySQLのマルチソースコピーを試してみてください.
私たちはMySQLのシングルマスターの従順、シングルマスターの多従、またはカスケードの主従アーキテクチャを知っています.私たちは多くのことを見ています.しかし、多主一は、図1のように、このような使用シーンから比較的少ない.
このアーキテクチャは一般的に以下の3つのシーンで使用されます.
1.複数のサーバのデータを1台にバックアップする
データの分割方向で言えば、垂直分割です.たとえば図2では、ビジネスA、B、C、Dは以前に分割されたビジネスであり、これらの分割されたビジネスをまとめてバックアップする必要があります.このようなニーズは、マルチソース・レプリケーション・アーキテクチャにも適用されます.
実装方法私は大まかに説明します:業務A、B、C、Dはそれぞれ4台のサーバーに位置して、各サーバーはそれぞれ1つのデータベースがフロントエンドの業務データを隔離して、それでは、ライブラリから4台の業務のデータをすべてまとめることができて、余分な操作をする必要はありません.マルチソースレプリケーションがない前に、このようなニーズを実現するには、要約マシンに複数のMySQLインスタンスを構築するしかありません.これは、ライブラリ間関連の問題に関連し、パフォーマンスが急激に低下するだけでなく、複数のインスタンスを管理するのも単一の容易ではありません.
2.フロントエンドの複数のサーバを集約するためのスライスデータ.
同様に,データ分割方向では水平分割に属する.例えば図3では、年ごとに分割されたデータをまとめて表示するには、このアーキテクチャも適切です.
実装方法は少し複雑です.例えば、すべてのサーバが同じデータベースとテーブルを共有し、一般的に極端に透明な開発のために、フロントエンドにはライブラリ分割テーブルのミドルウェア、例えば愛可生のDBLEが配置されています.
3.複数のサーバのデータをまとめて集計する
第3のクラスは第1のシーンと似ています.異なるのは、データがターゲットに集約されるだけでなく、これらのデータを統合する必要があることです.これは、最初のものよりも複雑です.例えば図4では、このようなニーズは、マルチソースレプリケーションにも適しているのではないでしょうか.答えはYESです.
具体的にはどうすればいいのでしょうか?
例えば、次の表Aのように、フィールドはID(プライマリキー)、F 1、F 2、F 3...、F100.では、このような分け方で、フロントエンドの4台のServerの表はそれぞれ次のようになります.

A1(ID,F1,F2,...,F25)

A2(ID,F26,F27,...,F50)

A3(ID,F51,F52,...,F75)

A4(ID,F76,F77,...,F100)

では、上の数枚のテーブルのデータをテーブルAにマージする場合は、Eventを作成し、タイミングよくテーブルAにデータを挿入することができます.コアSQLは次のとおりです.

insert ignore into A select A1.ID,F1,F2,...,F100 \
from A1 natural join A2 natural join A3 natural join A4;

これは最初と似ていることがわかりましたが、すべてのテーブルが最後に同じデータベースにコピーされました.
まとめて、MySQLのマルチソースコピーの3つの一般的な使用シーンを簡単に説明しましたが、皆さんに役に立つと思います.