不可抗力、データベースが配置されているサーバーがリサイクルされている、またはサーバーのディスクが破損している場合、データベースを移行する必要がありますか?

シングルポイントデータベースの読み取りおよび書き込みの負荷が増加しています。読み取りおよび書き込みの負荷を共有するために 1 つ以上のノードを拡張する必要がありますか?

1 つのテーブルのデータ量が大きすぎます。水平または垂直に分割する必要がある場合はどうすればよいですか?

データベースを mysql から PG、OB などの他のデータベースに移行する必要があります。

多くの学生にとって、上記のシナリオは多かれ少なかれ自分のビジネスに関係しているかもしれません。遭遇したことがなくても問題ありません。そのような問題が発生したら、どう対処すればよいでしょうか。この記事ではある程度の紙面を使って、制作実践経験と合わせて詳しく解説していきます。

2. データ移行シナリオ

一般に、さまざまなビジネスシナリオには、データ移行のモードと要件が異なります。データベース全体のサーバーレベルの移行が必要な場合もあれば、テーブルデータの移行のみが必要な場合もあれば、データベースのみの移行が必要な場合もあります。で一部のテーブルを移行します。次に、以下は、実稼働環境での実際の経験に基づいた、データ移行に関連するいくつかのシナリオの概要です。

2.1 データベース全体の移行

データベース全体を移行する必要がある主な理由は次のとおりです。

サーバーはリサイクルされます。
ディスク容量が不十分です。
ディスクの破損。
プロジェクトのマイクロサービス変換にはデータベースの分割が必要です...

データベースが物理マシンに展開されている場合、データベース全体の移行が一般的ですが、特別な理由で物理マシンがリサイクルされたり、ディスクが損傷したりする可能性があるため、物理マシン上のデータベースを全体として移行する必要があります。

一部のシナリオでは、運用上の問題シナリオを復元するために、開発環境またはテスト環境を再現できない場合、データベースデータ全体の移行が必要になる場合があり、運用データのコピーを自作マシン。

2.2 テーブルデータの移行

次のようなシナリオに遭遇したかどうかはわかりません。

新しいフィールドの追加など、実稼働テーブルの構造が変更されましたが、更新を停止したくない場合。
特定のテーブル内のデータ量が大きすぎるため、システムのパフォーマンスのボトルネックになっており、データテーブル内のデータを水平または垂直に分割する必要があります。
プロジェクトが変更されると、特定のデータベース内の特定のテーブルのデータを別のデータベースに完全に移行する必要があります。

テーブルデータの移行は、通常、単一テーブルのデータボリュームをセグメント化する必要があるときに発生します。このとき、ツール、SQL スクリプト、ストアドプロシージャ、または外部プログラムなどの特定の手段が必要になります。

2.3 mysqlのバージョン変更

エディターの過去の経験では、本番環境では mysql が 5.7 から 8.X にアップグレードされましたが、異なるバージョンのデータベースでは文字セットのエンコードやその他の点が大きく異なるため、下位バージョンのデータが直接使用されます。使用するまでにかなりの紆余曲折を経験し、いくつかの落とし穴を経て、ようやく完成しましたそのため、mysql などのリレーショナルデータベースのバージョンアップとなると、データ移行が発生する可能性が高くなります。関与することになる。

2.4 mysql データを他のストレージメディアに移行する

例えばプロダクトの構造を調整する場合、調整前はmysqlなどのリレーショナルデータベースに業務データを格納していましたが、構造を調整した後はesやmongoなどにデータを二重書きする必要があります。、hbase などのストレージメディアこのとき、新しく追加したストレージメディアをできるだけ早く使用できるようにするには、mysql データを新しいストレージメディアに合わせて調整する必要があり、これにはデータの移行が伴います。これは実際の運用では一般的なシナリオです。

2.5 自社構築データをクラウド環境へ

パブリッククラウドが本格的に導入される前の初期には、多くの企業が自社でサーバーを購入して独自のデータベースを構築したり、ある程度の規模の企業が自社のコンピュータ室やデータセンターを構築したりしていましたが、パブリッククラウドの台頭と普及により、サービスがクラウド上に登場すると、必然的に自社で構築したデータのクラウド環境へのデータ移行作業に直面することになる。

2.6 mysqlデータを国内の他データベースへ

近年、外部環境の影響により、多くのインターネット企業でセキュリティ問題が提起され、GAUSSやDamengなどの国内データベースが急増しています。国内のデータベースと互換性を持たせるためには、mysql データをこれらのローカライズされたデータベースに移行する作業が必然的に発生します。

3. データベースの物理移行実施計画

上記では、データ移行が発生する可能性のあるいくつかの一般的なシナリオをより詳細にまとめましたが、シナリオが異なると、特定のデータ移行に対処する戦略も異なり、業界で一般的なシナリオを設定することは困難です。、実際の制作経験と組み合わせて、参考として比較的実現可能な解決策とアイデアをいくつか紹介します。

3.1 データベースの物理移行の概要

物理的な移行は、大規模なデータの全体的な移行に適しています。元のデータファイルを直接コピーすることも、バックアップ移行に navicat クライアントツールを使用することもできます。異なるサーバー間で物理的に移行するには、2 つのサーバーで MySQL サーバーのバージョン、構成、権限を同じに保つ必要があります。

この種の物理的な移行の利点は高速であることですが、欠点は、新しいサーバーの構成が元のサーバーとまったく同じである必要があり、それでも不明なエラーが発生する可能性があることです。

3.1.1 物理的な移行に適用されるシナリオ

サーバー全面リプレースによるデータ移行など、大容量データの全体移行に適しています。

3.1.2 物理的な利点と欠点

アドバンテージ

データの詳細を考慮する必要がなく、移行速度が比較的速い

欠点がある

移行の前後でデータの一貫性を確保するには、ダウンタイムが必要になる場合がありますが、柔軟性が低く、未知のエラーの予測が困難です。

次に、ケースを使用して、物理的な移行の完全な手順を示します。

3.2 物理移行のためのデータファイルのコピー

準備

1. 2 台のサーバー (それぞれ IP1 と IP2)。

2. 2 つのサーバー上に mysql 環境を事前に準備します。これは docker を使用してすぐに構築できます。

3.2.1 データファイルレプリケーションの概要

mysql データベースを使用したことがある学生は、mysql データストレージファイルに精通している必要があります。5.7 を例として挙げると、特定のデータベースでは、テーブルデータファイルを記録するための ibd など、mysql データディレクトリの下にこのデータベース用の多くのファイルディレクトリが作成されます。、テーブル情報などを記述したfrmファイル。

したがって、理論的には、データファイルをコピーしてデータ移行を実現するには、データベースのデータディレクトリファイルの完全なコピーを作成し、mysql データディレクトリとターゲットマシンの構造を同じに保つだけで済みます。

3.2.2 最初のマシンでデータベースを作成する

IP1 マシン上にデータベース db_emp を作成し、そのデータベースの下にテーブル t_user を作成し、t_user テーブルのデータを挿入します。

この時点で、mysql データディレクトリの下に、ライブラリに関するデータディレクトリが表示されます。

3.2.3 最初にコピーするマシンにファイルをコピーする

データコピーの移行プロセス中に発生するその他の問題を最小限に抑えるために、2 つのマシン上の mysql バージョンの一貫性を保つように努め、mysql データディレクトリの場所も一貫している必要があることに注意してください。、マウントされたデータディレクトリ設定は一貫しています。

コピーする必要があるファイルディレクトリは次のとおりです（mysqlディレクトリをコピーする必要はないという学生もいましたが、ここで試してみたところうまくいったようです）

次に、上記のディレクトリを IP2 マシン上の同じ場所にコピーします。コピーする前に、IP ディレクトリにそのようなファイルがないことを確認してください。

データファイルをコピーするには、ftp ツールを使用するか、直接 scp を使用し、コピーの完了後に解凍します (以前のデータディレクトリをバックアップする必要があることに注意してください)。

コピーが完了したら、ファイルを解凍します。解凍が完了したら、mysql サービスを再起動し、クライアントを使用して接続します。問題がなければ、同じデータベースとテーブルデータが表示されます。

3.3 物理的な移行のためのツールの移行

上記の操作から、データディレクトリのコピーを直接使用するプロセスは依然として非常に煩雑であり、移行するデータベースファイルのサイズが大きい場合、プロセスに非常に時間がかかる可能性があります。もちろん、運用環境でクライアントツールの使用が許可されている場合は、クライアントツールを使用してデータベース全体のデータの移行を連携することも検討できます。上記のデータベースを例として取り上げ、具体的な操作プロセスを見てみましょう。

3.3.1 IP2 上のデータベースを削除する

デモンストレーションの効果を確実にするために、まず IP2 上のデータベースを削除します。

3.3.2 IP1 でデータベースをエクスポートする

navicat ツールを使用して IP1 の mysql サービスに接続し、db_emp のデータベースを SQL ファイルとしてエクスポートします。

データ量が少ないためエクスポートが速い

3.3.3 SQL ファイルを IP2 にインポートする

SQL ファイルを実行し、上でエクスポートした SQL を navicat 経由でインポートしますが、この操作は通常多くの学生が行う必要があるため、詳細は説明しません。

4. データベースロジック移行の実施計画

物理的な移行は単純で大まかに見えますが、実際には、運用の実践、特に多くのマイクロサービスや大規模なデータベースが存在する環境では、物理的な移行は一般的なソリューションではありません。

4.1 物理的な移行の欠点

十分な柔軟性がありません

移行前後のデータの一貫性を確保するには、オンラインで実行されているサービスをシャットダウンして再移行する必要がある場合がありますが、これには十分な柔軟性がありません。

データが大きすぎます

実際の運用環境では、データベースのファイルサイズは G では小さく、T では動的になります。この種のクロスマシンコピー速度とネットワーク要件は想像を絶します。

バックアップのトラブル

以前のデータファイルをバックアップすると、多くのディスクストレージ容量が必要になり、ファイル数が多くファイルサイズが大きすぎると、バックアップに時間がかかります。

一貫性を保証するのが難しい環境

実際、上記のように、データレプリケーションの前後でデータディレクトリや他のマシンの環境の整合性を確保することは困難であり、実際には、サーバー環境の要因によって制御不能な困難が多く発生することが多く、これが多くの開発エンジニアの理由です。運用および保守エンジニアにとっては頭の痛い問題です

実際の運用では、より多くの予測不可能な要因により、物理的な移行は好ましいデータ移行ソリューションではなくなるため、ほとんどの場合、DBA や運用保守担当者は論理的な移行を好みます。

上記の db_emp を例として取り上げ、具体的な操作手順を見てみましょう。

4.2 ロジカルマイグレーションの特徴

物理的な移行と比較して、論理的なデータベースの移行には明らかな利点があり、特に次のようなさまざまなシナリオに適用できます。

4.2.1 論理移行のメリットとデメリット

アドバンテージ

高い互換性、柔軟で便利、クロスバージョン、比較的小規模なファイル転送

欠点がある

移行時間が非常に長くなる可能性があります。論理移行の原則は、MySQL データベースのデータとテーブル構造を SQL ファイルに変換することです。バックアップ SQL ファイルが特に大きい場合、解析と変換プロセスに長い時間がかかります

4.2.2 論理移行時の注意事項

1. 移行する必要のないライブラリまたはデータテーブルを確認します。

2. 大きなテーブルの個別の処理。

3. 移行が完了したらすぐにデータを検証します。

4.3 データベースロジックのバックアップとリカバリ

mysql データベースデータテーブルの論理バックアップについては、ここでは詳しく説明しません。この記事の焦点ではありません。興味のある学生は、この記事を参照してください: mysql データのバックアップとリカバリ。簡単に言えば、論理バックアップの核心は、mysqldump コマンドデータベースのデータテーブルをバックアップし、このファイルに基づいてデータのリカバリまたは移行を実行します。

4.3.1 データベースバックアップコマンドの実行

次のデータベースバックアップコマンドを実行して、db_emp データベースをバックアップします。

mysqldump -uroot -p パスワード --databases db_emp > /var/lib/mysql/db_emp.sql

実行が完了すると、SQL ファイルが現在のディレクトリにエクスポートされたことがわかります。

4.3.2 SQLファイルのコピー

上記でバックアップしたデータベースファイルを 2 台目のマシンの同じディレクトリにコピーします。

4.3.3 バックアップデータのリストア

IP2のmysqlサービスにログインし、以前のdb_empデータベースを削除します。

以下のコマンドを実行してデータを復元します

mysql -uroot -あなたのパスワード < /var/lib/mysql/db_emp.sql

実行が完了したら、IP2 の mysql を再度確認すると、データが移行されたことがわかります。

5. アプリケーション移行実施計画

実際のビジネスでは、次のようなシナリオが存在する可能性があります (実際のビジネス要件から派生したもの)。

プロジェクトサイトには専門の実装担当者やデータベースに精通した担当者がいません。
データベース内の一部のビジネステーブルでは、フィールドが時々増減することがあります。
オフサイトの高可用性には、データのバックアップ、増分バックアップまたは完全バックアップが必要です。
データの追加、削除、変更など、一部のテーブルの特定の変更イベントのデータのみをバックアップする必要があります。
他の業務用途の一部のテーブルデータについては、新しいテーブルを異種混合で合成する必要がある...

まとめると、上記のシナリオの特徴として、移行が必要なデータシナリオには特殊性があったり、個別化されたシナリオであったりするため、固定的な方法では対応が難しいということが挙げられます。プログラムを通じてそれを解決するのは良い選択です。

いざ実践となると、どうやって実践すればいいのでしょうか？いくつかの一般的なシナリオと組み合わせて、一般的に使用されるいくつかの処理ソリューションを以下に示します。

5.1 ビジネスケースの要件と実装 1

アプリケーション A のデータベースにテーブルがあり、テーブル A のデータの一部のフィールドデータを別のデータベースに保存し、同時に統計を収集し、特定のインジケーターの結果をデータベースに集計する必要があります。大画面表示用アプリケーションB

需要分析

上記の要件の説明から、次の重要な点を抽出できます。

操作はデータベース内の特定のテーブルです。
移行する必要があるのは、テーブル内のデータの一部です。
統計計算は既存のテーブルデータに対して実行する必要があります。

上記の元々のニーズと要件の分析を組み合わせると、SQL 移行を通じてこの要件を直接達成することは困難です。一般的に使用される実装ソリューションをいくつか次に示します。

mysql のストアドプロシージャを介して;
論理移行では、移行完了後、手動で修正、計算、計算結果の入力を行います。
プログラムを通じて完了します。

明らかに、1 番目と 2 番目の方法の実装は柔軟性が十分ではなく、ダウンタイム操作が発生する可能性がありますが、この問題を解決するには中間プログラムを検討できます。ここでは、Ali のオープンソースミドルウェア運河を実装することをお勧めします。

5.1.1 canal を使用してデータ移行を完了する

canal は、Ali によってオープンソース化された mysql データベース同期ツールであり、その主な目的は、MySQL データベースの増分ログ分析に基づいて、増分データのサブスクリプションと消費を提供することです。運河の git アドレス

運河の実装原理を次の図に示します。

è¿éæå¥å¾çæè¿°

アプリケーションプログラムに特有のものですが、運河はどのようにして上記の要件を達成できるのでしょうか? 実際、canal を使用すると、canal はターゲットデータテーブル内のさまざまなイベント変更を監視できるリスナーに相当し、さまざまなデータ変更イベントをリッスンした後、変更されたログを分析して処理できることが簡単に理解できます。プログラムを直接インストール、展開、簡単な設定、サーバー上で使用するクライアント側の SDK も提供されており、この SDK をベースに上記のビジネスを実現するためのエントリポイントとなります。

上記の要件に対応付けると、完全な実装アイデアは次のようになります。

事前にサーバー運河を設定します。
クライアントは canal の SDK を導入します。
アプリケーションは、指定されたデータ変更イベントをリッスンし、データを新しいテーブルに書き込みます。
アプリケーション統計は、結果を新しいテーブルに集計します (このステップは他の場所でも実行できます)。

5.1.2 canal実装サンプルコード

中間プログラムのサンプルコード (完全な実装については、公式デモケースを参照してください)

import com.alibaba.fastjson.JSONObject;
import com.alibaba.otter.canal.client.CanalConnector;
import com.alibaba.otter.canal.client.CanalConnectors;
import com.alibaba.otter.canal.protocol.CanalEntry;
import com.alibaba.otter.canal.protocol.Message;
import com.google.protobuf.ByteString;

import java.net.InetSocketAddress;
import java.util.List;

public class CanalClient {

    public static void main(String[] args) throws Exception{

        //1.获取 canal 连接对象
        CanalConnector canalConnector =
                CanalConnectors.newSingleConnector(new
                        InetSocketAddress("canal所在服务器IP", 11111), "example", "", "");

        System.out.println("canal启动并开始监听数据 ...... ");

        while (true){
            canalConnector.connect();
            //订阅表
            canalConnector.subscribe("shop001.*");

            //获取数据
            Message message = canalConnector.get(100);

            //解析message
            List<CanalEntry.Entry> entries = message.getEntries();
            if(entries.size() <=0){
                System.out.println("未检测到数据");
                Thread.sleep(1000);
            }

            for(CanalEntry.Entry entry : entries){
                //1、获取表名
                String tableName = entry.getHeader().getTableName();

                //2、获取类型
                CanalEntry.EntryType entryType = entry.getEntryType();

                //3、获取序列化后的数据
                ByteString storeValue = entry.getStoreValue();

                //判断是否rowdata类型数据
                if(CanalEntry.EntryType.ROWDATA.equals(entryType)){
                    //对第三步中的数据进行解析
                    CanalEntry.RowChange rowChange = CanalEntry.RowChange.parseFrom(storeValue);
                    //获取当前事件的操作类型
                    CanalEntry.EventType eventType = rowChange.getEventType();

                    //获取数据集
                    List<CanalEntry.RowData> rowDatasList = rowChange.getRowDatasList();

                    //便利数据
                    for(CanalEntry.RowData rowData : rowDatasList){

                        //数据变更之前的内容
                        JSONObject beforeData = new JSONObject();
                        List<CanalEntry.Column> beforeColumnsList = rowData.getAfterColumnsList();
                        for(CanalEntry.Column column : beforeColumnsList){
                            beforeData.put(column.getName(),column.getValue());
                        }

                        //数据变更之后的内容
                        List<CanalEntry.Column> afterColumnsList = rowData.getAfterColumnsList();
                        JSONObject afterData = new JSONObject();
                        for(CanalEntry.Column column : afterColumnsList){
                            afterData.put(column.getName(),column.getValue());
                        }

                        System.out.println("Table ：" + tableName +
                                ",eventType :" + eventType +
                                ",beforeData :" + beforeData +
                                ",afterData : " + afterData);

                    }
                }else {
                    System.out.println("当前操作类型为：" + entryType);
                }
            }
        }
    }
}

5.2 ビジネスケースの要件と実装 2

要件の説明

業務システムでは、あるテーブルのデータを複数のストレージに更新する必要、つまり、mysql のあるテーブルのデータが変更された後、更新する必要があるなど、上記の要件のアップグレードが必要になることがよくあります。別のデータベースに同期的に送信され、es、redis、mongo、その他のストレージにも同期的に更新されます

このような需要シナリオでは、flink-cdc の実装というより良い選択肢があります。

5.2.1 Flink-cdc 実装の原則とアイデア

以下の図は公式サイトに掲載されている flink cdc 実装に関する業務フロー図ですが、これが canal の実装原理と非常に似ていることは理解するのに難しくありません。

è¿éæå¥å¾çæè¿°

この要件を達成するために flink cdc を使用する場合、大まかに次のアイデアに従って実行できます。

1. MySQL 設定のバイナリログ。

2. プログラムは SDK の依存関係を導入します。

3. プログラムを作成し、ターゲットテーブルのデータ変更イベントを監視し、ターゲットテーブルにデータを書き込みます。

5.2.2 flink-cdc はキーコードを実装します

flink-cdc を使用して実装されたサンプルコードを以下に示します。興味のある学生は詳しく学ぶことができます。

import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.table.api.Table;
import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;
import org.apache.flink.types.Row;

public class CdcTest2 {

    public static void main(String[] args) throws Exception{

        //1.创建执行环境
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

        env.setParallelism(1);
        StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

        //2.创建 Flink-MySQL-CDC 的 Source
        tableEnv.executeSql("CREATE TABLE user_info1 (" +
                " id STRING NOT NULL," +
                " name STRING NOT NULL," +
                " version INTEGER NOT NULL" +
                ") WITH (" +
                " 'connector' = 'mysql-cdc'," +
                " 'hostname' = 'IP'," +
                " 'port' = '3306'," +
                " 'username' = 'root'," +
                " '连接密码' = '连接密码'," +
                " 'database-name' = 'bank1'," +
                " 'table-name' = 'record'" +
                ")");

        //tableEnv.executeSql("select * from user_info1").print();

        Table table = tableEnv.sqlQuery("select * from user_info1");
        DataStream<Tuple2<Boolean, Row>> retractStream = tableEnv.toRetractStream(table, Row.class);

        //结果打印输出
        retractStream.print();

        env.execute("flinkCdcSql");

    }

}

6. オフラインでのデータ移行を実現するミドルウェア

データ移行の需要の高まりに伴い、データベースデータテーブルの移行を完了するために、使いやすいオープンソースミドルウェアがいくつか市場に登場しています。ここでは、データ同期用に一般的に使用され、比較的安定しているミドルウェアをいくつか紹介します。

6.1 カナルはデータの移行または同期を実現します

上記では、canal の機能と、プログラムと組み合わせてデータ同期を完了するプロセスを簡単に紹介しましたが、実際、canal の機能は依然として非常に強力で、データ同期を行うことができ、mysql データを他のプログラムにインポートすることもできます。ストレージ、さらにはアプリケーションプログラムと連携して、複雑で特殊なシーンの実現を完了します。

6.1.1 カナルを使用してデータの移行または同期を実現する

一般的に、canal を使用してデータの移行または同期を実現するには、次の手順を参照してください。

1. 運河サーバーをインストールします。

2. 構成ファイルを追加し、ソースデータベース、データテーブルアドレスを構成し、ターゲットデータベース、データテーブルアドレスを構成します。

3. 2 番目のステップに基づいて、テーブル内の特定のイベントの変更データのみを同期するなど、より詳細な設定を行うことができます。また、要件に応じて増分同期または完全同期を設定できます。

4. 構成ファイルが完了したら、サービスを開始します。

5. 構成によって直接解決できない場合は、アプリケーションコードを使用してより複雑な操作を完了できます。

6.2 datax によるデータ移行の実装

6.2.1 データックスの概要

DataX は、Ali 内で広く使用されているオフラインデータ同期ツール/プラットフォームで、MySQL、Oracle、HDFS、Hive、OceanBase、HBase、OTS、ODPS などを含むさまざまな異種データソース間の効率的なデータ同期を実現できます。DataX はフレームワーク + プラグを採用しています-in モードは現在オープンソースであり、コードは github、datax git アドレスでホストされています。

6.2.2 データックスの機能

データ同期フレームワークとして、DataX は、さまざまなデータソースの同期を、ソースデータソースからデータを読み取る Reader プラグインと、ターゲットエンドにデータを書き込む Writer プラグインに抽象化します。あらゆるデータソースタイプのデータ同期をサポートします。同時に、DataX プラグインシステムはエコシステムとして機能し、新しいデータソースが接続されるたびに、新しく追加されたデータソースは既存のデータソースと通信できます。

6.2.3 適用可能なシナリオ

通常、サービスが一時停止されると、データの一部が、あるデータベースから別のデータベースに、または他の異なる種類のデータベースに移行されます。

6.2.4 datax はデータ移行プロセスを実装します

datax を使用したデータ移行の一般的なプロセスは大まかに次のとおりです。

1. インストールパッケージをダウンロードして解凍します。

2. 構成ファイルを作成して、元のデータベース、テーブル、接続、および同期するその他の情報を構成します。

3. ターゲットデータベース、データベース、テーブルなどの情報を設定します。

4. datax では、データ型が正しい限り、ソーステーブルとターゲットテーブルの名前が同じである必要はなく、フィールドさえも完全に一致している必要はありません。

5. 構成ファイルに対してコマンドを実行して、データのオフライン移行を完了します。

6.2.5 datax データ移行のシミュレーション構成

以下にdataxを利用したデータ移行の設定情報を記載しますので、詳しくは公式情報をご参照ください。

{
    "job": {
        "setting": {
            "speed": {
                 "channel": 3
            },
            "errorLimit": {
                "record": 0,
                "percentage": 0.02
            }
        },
        "content": [
            {
                "reader": {
                    "name": "mysqlreader",
                    "parameter": {
                        "username": "连接用户名",
                        "password": "连接密码",
                        "column": [
                            "id",
                            "name"
                        ],
                        "connection": [
                            {
                                "table": [
                                    "user_info"    #表名
                                ],
                                "jdbcUrl": [
     "jdbc:mysql://IP1:3306/shop001"			#源地址
                                ]
                            }
                        ]
                    }
                },
               "writer": {
                    "name": "streamwriter",
                    "parameter": {
                        "print":true,	#开启任务运行过程中的打印
	       "column": [
                        "id","name"		#待同步的字段
	         ], 
	    "connection": [
                            {
                                "jdbcUrl": "jdbc:mysql://IP2:3306/shop001", 		#目标地址
                                "table": ["user_info_copy"]		#目标表
                            }
                        ], 
                        "password": "连接密码", 
                        "username": "连接用户名"
                    }
                }
            }
        ]
    }
}

7. クライアントツールのオフラインデータ移行

日常業務において、リアルタイム要件がそれほど高くなく、データ量が特に大きくない場合は、いくつかのクライアントツールを使用してデータ移行作業を完了することもできます。以下では、データを支援するために一般的に使用されるいくつかのクライアントツールを紹介します。移行作業。

7.1 ナビキャット

Navicat は皆さんもよくご存知だと思いますが、mysql、PG、OB などの多くのデータベースへの日常的な接続や使用に対応できるだけでなく、日々の開発や運用保守の中で遭遇することになるクライアントツールです。だけでなく、一部の定期的なデータ移行作業の完了も支援します。たとえば、mysql データベースを postgresql に移行するプロセスは、navicat クライアントを通じて簡単に完了できますので、具体的な操作手順を見てみましょう。

7.2 Navicat は mysql データを postgresql に移行します

7.2.1 準備

データを移行する前に、新しい MySQL および PostgreSQL 接続を作成し、接続アカウントにデータベースを移行するためのすべての権限があることを確認する必要があります。

7.2.2 構成の移行

メニュー [ツール] >> [転送] をクリックすると、次のウィンドウが表示されます。ソース MySQL とターゲット PostgreSQL データベースを選択します。

7.2.3 移行するテーブルの選択

データベースの下のすべてのテーブルを選択します

7.2.4 エラーが発生した場合は続行にチェックを入れます

その理由は、MySQL のインデックスはテーブル内で一意ですが、PostgreSQL のインデックス名はグローバルに一意であるためです。同期中に関連するエラーが発生した場合は、SQL の補足が後で提供されます。

以上の操作手順により、mysqlからpgへのデータ移行が完了します。

7.3 やかん

7.3.1 ケトルの概要

Kettle の中国語名は Kettle です。このプロジェクトのメインプログラマは、あらゆる種類のデータを鍋に入れ、指定された形式で流出させることを望んでいます。Kettle はデータ移行、つまりすべてのデータを転送するために使用されます。データベース別のデータベースをインポートします。

Kettleこれは外国のオープンソースETLツールで、純粋にJava作成され、インストール不要で環境に優しく、効率的で安定したデータ抽出 (データ移行ツール) です。

7.3.2 Kettle データの移行プロセス

Kettle はビッグデータ ETL で広く使用されており、開いた後は、navicat と同様のインターフェイスを備えたクライアントを介してさまざまな操作を直接設定できます。大まかな考え方は上記の navicat と同様です。

Kettle は、mysql データベース間のデータのオフライン移行に使用できるだけでなく、mysql から mogo へなど、異なる種類のデータベース間の移行も実現できます。

八、本文の最後に書いてある

この記事では、mysql のデータ移行または同期の一般的な処理スキームを詳細にまとめています。実際、運用環境での状況はこれらよりもはるかに複雑です。たとえば、mysql のマスター/スレーブモードでは、新しいスレーブノードを拡張する必要があります。ここでは比較的一般的なものをいくつか示します。ソリューションのアイデアは、後の作業で同様のシナリオに遭遇したときに参照できます。この記事はこれで終わります、ご覧いただきありがとうございました。

mysql データの移行と同期のための一般的なソリューションの概要

I.はじめに