最も明白なデータサイズが大きくなると、パフォーマンスのボトルネックが発生する最も人気の一つ、ソリューションとしてMySQLのリレーショナル・データベース製品は、サブライブラリーのサブテーブルにあります。それは水平または垂直分割分割されているかどうか、最初のステップは、必ずしもデータの移行および同期を必要とします。一連のデータは、要求の移行プロセスを誘導することができるれます。
1.もともと単一のデータベーステーブルマルチテーブル（またはマルチテーブル・ライブラリー）は、最も基本的なニーズである、への移行。
2.元の単一のマルチテーブルライブラリ（またはライブラリ複数のテーブル）は、（再びによる設計が不十分なデータのサイズが増加し、他の原因にテーブルサブライブラリーサブテーブルする必要がある）新しいライブラリと複数のマルチテーブルに移行します
表3.新しいテーブルの構造と古いテーブルのような、矛盾してもよい：複数種類のテーブル（自動インクリメントの主キーID BIGINTはintへの変更）等視差場（削除、増加）の数、フィールド名の変更、
前記のようなフィールドマッピング：フィールドマッピング複数の古いテーブルから新しいテーブル項目、またはテーブルの新しい複数の古いフィールドのフィールド・マッピング・テーブルに
インクリメンタルデータのリアルタイムの同期化、並びに変換テーブル構造に言及する場合、それは同じ変換を達成することがいかに簡単であるか増分部分（バイナリログ）
垂直分割データの移行をサポートするために、どのように6
（例えば：TiDB、CockroachDB）NewSQLマイグレーション7.MySQL
HBaseの、MongoDBのにMySQLの（異種データ・ソースにリアルタイムでこの記事設計範囲を同期されていない、その後のプレゼンテーション）などの8ライブマイグレーション異種データソース、
9.整合性チェックデータ移行の前と後
これらの要件を満たすために、完全な移行と二つの部分の増分同期から以下の金額は、データ移行のMySQL同期ツールの設計と実装を説明します。
mysqldumpは、MySQLがデータのバックアップツールが付属して公式には、データ移行を使用することも可能ですが、欠点は、大きなテーブルを移行し、サブライブラリーサブテーブルを書き込みをサポートしていない場合、極端に遅くシングルスレッド処理です。そのため、オープンソースコミュニティでも、マルチスレッドmydumper同様のツールを開発している、そこのパフォーマンスのアップグレードの多くがありますが、また、サブライブラリーサブテーブルを書いてサポートしていません、フィールドの変換をサポートしていません。
以下の下で並列に読ん高速フラグメンテーションMySQLのテーブルデータの練習を説明します。
図1に示すように、自動ルックアップテーブルの主キーPK。
2、最大値と主キー問合せの最小値：MAX（PK）、分（PK）。
複数のクエリ断片に3、主キー範囲スライス、各スライスが10,000に及ぶ（すなわち、10000までのデータラインを読み取る）、クエリにすることにより全体表：
クエリ条件の断片は、PK> =分（PK）およびPK <分（PK）+10000あります
第2の断片は、クエリPK> =分（PK）+10000 AND PK <分（PK）2万あります
第三のフラグメント照会条件は、PK> =分（PK）2万AND PK <分（PK）3万あります
などなど。
上記のクエリの断片に加えて、並行して読み取ることができ、別の利点は、回復可能な障害があり、単純に再試行に失敗し、照会の全体的な進行には影響しないスライスのクエリに失敗しました。もちろん、全ての断片が永続することができ、プログラムが予期せず終了した場合でも、再クエリテーブル全体のデータを避けるために、再起動後に復元することができます。
インクリメンタルデータは、プライマリのbinlog MySQLの上のコピーから読み取ります。最初のサイトから再生を継続BINLOGデータ移行が完了した後に全額への移行の全額前に、現在のMySQLのサイトの情報（ファイル名、位置）を取得します。
複数の平行なテーブルは、クエリフラグメント（クエリスプリット）を生成し、ソースは、MySQLからデータを読み出す並列クエリのフラグメントによって実行され、：RxJavaオブザーバは、並列処理モードを最大限に基づいてチェーン（生産者又は消費者）を達成しバッチサイズときにスロットに挿入されたときシンクセレクタフィールドとスロットのサブルールデータベースシャーディングサブテーブルによるユニファイドコンピューティングは、データの各行（すなわち、シートがサブテーブルを書き込まれる場合）、データ蓄積を生成する属しますシンク平行バッチによって断片（挿入スプリット）、そして最終的には、対応するターゲット・テーブルを書き込みます。
所定のタイムスロットは、バッチサイズよりも多くの挿入スプリットを生成するために蓄積されない場合であっても後に、GC圧によるデータの過剰な蓄積を避けるためにシンクの書き込みが行われる分散。また、私たちは別の問題を検討する必要があります。生産者が消費者に対処するために手遅れで迅速な結果を生成するとき、それOOM、いわゆる背圧（バックプレッシャー）がそれほど深刻なイベントの蓄積につながります。幸いなことに、成熟した反応FrameworkなどRxJavaはRxJavaに基づいて重要な理由の一つは達成する理由である、背圧プロセスのための良いサポートを持っています。
運河、明確かつ理解しやすいソースコード、その他のサードパーティのjarパッケージ、そんなにいない不要な複雑な機能の独立したと比べてbinlogの抽出、オープンソースのJavaライブラリのmysql-binlogのコネクタ-Javaを使用して、より軽量。
为了实现对binlog的字段转换，采用了Apache开源的SQL引擎calcite来实现：将binlog的每行数据根据原表的表结构映射为一张内存表，然后由calcite执行SQL转换后输出结果。（PS：calcite当前已被多个开源项目采用，Hive用calcite优化查询，Flink的Streaming SQL基于calcite实现，Kylin的查询引擎也采用calcite）
因MySQL表的checksum与数据的行顺序无关，当新表与旧表的表结构相同并且数据不需要转换时采用执行CHECKSUM TABLE tbl_name查询语句获取每张新表和旧表的checksum，然后分别求和对比最终的checksum是否相同以此校验数据是否一致。
当新表与旧表存在字段类型变更、字段数量不一致、数据经过转换等会导致checksum发生变化时，采用排除有关字段，由迁移工具内部只对剩余字段数据进行checksum计算。Checksum算法可以选择CRC32或Adler32，这两种算法均采用Java自带的实现类，默认情况下使用Adler32因为其具有更快的计算效率。
无论是分库分表常规方案的实施，还是未来新一代分布式关系型数据存储NewSQL的落地实践，数据的迁移与同步都是必不可少的重要环节。毕竟，快速、准确、平滑地完成数据迁移，便已成功了一半。