碑文
Elasticsearch中国コミュニティからの質問-
MySQLには、テーブルに一意の増分フィールドと一意の増分時間フィールドはありません。logstashを使用して、MySQLからesへのリアルタイムの増分データインポートを実現するにはどうすればよいですか。
logstashとkafka_connectorはどちらも、自己インクリメントIDまたはタイムスタンプ更新に基づくデータのインクリメンタル同期のみをサポートします。
質問自体に戻ります。ライブラリテーブルに関連するフィールドがない場合は、どうすればよいですか。
この記事では、関連する議論と解決策を示します。
1.ビンログ認識
1.1 binlogとは何ですか？
Binlogは、Mysqlサーバーレイヤーによって維持されるバイナリログです。InnoDBエンジンのREDO / UNDOログとは完全に異なるログです。主に、mysqlデータを更新または更新する可能性のあるSQLステートメントを記録し、「トランザクション」を使用するために使用されます。フォームはディスクに保存されます。
主な機能は次のとおりです。
- 1）レプリケーション：一貫したマスタースレーブデータの目標を達成するため。
- 2）データ回復：mysqlbinlogツールを使用してデータを回復します。
- 3）インクリメンタルバックアップ。
1.2 Ali'sCanalは増分Mysql同期を実現します
Canalは、データベースの増分ログ分析に基づいてJavaで開発されたミドルウェアであり、増分データのサブスクリプションと消費を提供します。
現在、canalは主にMySQL binlog解析をサポートしており、解析が完了した後、canalクライアントを使用して関連データを処理します。目的：増分データサブスクリプションと消費。
要約すると、binlogを使用すると、IDを自己インクリメントしたり、タイムスタンプフィールドを設定したりせずに、logstashまたはkafka-connectorの制限を突破し、インクリメンタル同期を実現できます。
2.binlogに基づく同期方法
1）kafka Connectに基づくDebeziumオープンソースプロジェクト、アドレス：https：//debezium.io/
2）サードパーティに依存しない独立したアプリケーション：Maxwellオープンソースプロジェクト、アドレス：http：//maxwells-daemon.io/
conluent（zookeeper、kafka、ksql、kafka-connectorなどが付属するエンタープライズバージョンのkafka）が展開されているため、この記事はDebeziumのみを対象としています。
3.Debeziumの紹介
Debeziumは、データの動的な変化をリアルタイムでキャプチャするオープンソースの分散同期プラットフォームです。データソース（Mysql、Mongo、PostgreSql）のリアルタイムキャプチャ：追加（挿入）、更新（更新）、削除（削除）操作、Kafkaへのリアルタイム同期、強力な安定性と非常に高速。
特徴：
- 1）シンプル。アプリケーションを変更する必要はありません。外部サービスを提供できます。
- 2）安定している。すべての行のすべての変更を追跡します。
- 3）速い。Kafka上に構築されており、スケーラブルであり、公式の検証後に大容量のデータを処理できます。
4.同期アーキテクチャ
図に示すように、MysqlからESへの同期戦略は、「国を救うための曲線」メカニズムを採用しています。
ステップ1：Debeziumのbinlogメカニズムに基づいて、MysqlデータをKafkaに同期します。
ステップ2：Kafka_connectorメカニズムに基づいて、KafkaデータをElasticsearchに同期します。
5. Debeziumは、MysqlからESの追加、削除、および変更へのリアルタイム同期を実現します
ソフトウェアバージョン：
コンフルエント：5.1.2；
デベジウム：0.9.2_Final;
Mysql：5.7.x。
Elasticsearch：6.6.1
5.1Debeziumのインストール
confluentのインストールと展開については、http：//t.cn/Ef5poZkを参照してください。ここでは、詳細については説明しません。
Debeziumのインストールでは、debezium-connector-mysqlの圧縮パッケージを解凍し、Confluentの解凍されたプラグインディレクトリ（share / java）に配置するだけです。
MySQLコネクタプラグイン圧縮パッケージのダウンロードリンク：
Debeziumを有効にするには、コンフルエントを再起動することに注意してください。
5.2 Mysqlbinlogおよびその他の関連する構成。
DebeziumはMySQLのbinlogメカニズムを使用してデータの動的な変更を監視するため、MySQLは事前にbinlogを構成する必要があります。
コア構成は次のとおりです。Mysqlマシンの/etc/my.cnfのmysqldの下に次の構成を追加します。
1[mysqld]
2
3server-id = 223344
4log_bin = mysql-bin
5binlog_format = row
6binlog_row_image = full
7expire_logs_days = 10次に、Mysqlを再起動して、binlogを有効にします。
1systemctl start mysqld.service5.3コネクタコネクタを設定します。
コンフルエントパスディレクトリを構成します：/ etc
フォルダの作成コマンド：
1mkdir kafka-connect-debeziumコネクタの構成情報をmysql2kafka_debezium.jsonに保存します。
1[root@localhost kafka-connect-debezium]# cat mysql2kafka_debezium.json
2{
3 "name" : "debezium-mysql-source-0223",
4 "config":
5 {
6 "connector.class" : "io.debezium.connector.mysql.MySqlConnector",
7 "database.hostname" : "192.168.1.22",
8 "database.port" : "3306",
9 "database.user" : "root",
10 "database.password" : "XXXXXX",
11 "database.whitelist" : "kafka_base_db",
12 "table.whitlelist" : "accounts",
13 "database.server.id" : "223344",
14 "database.server.name" : "full",
15 "database.history.kafka.bootstrap.servers" : "192.168.1.22:9092",
16 "database.history.kafka.topic" : "account_topic",
17 "include.schema.changes" : "true" ,
18 "incrementing.column.name" : "id",
19 "database.history.skip.unparseable.ddl" : "true",
20 "transforms": "unwrap,changetopic",
21 "transforms.unwrap.type": "io.debezium.transforms.UnwrapFromEnvelope",
22 "transforms.changetopic.type":"org.apache.kafka.connect.transforms.RegexRouter",
23 "transforms.changetopic.regex":"(.*)",
24 "transforms.changetopic.replacement":"$1-smt"
25 }
26}次の構成に注意してください。
- 「database.server.id」は、Mysqlのserver-idの構成に対応します。
- "database.whitelist"：同期するMysqlデータベースの名前。
- "table.whitlelist"：同期するMysqテーブルの名前。
- 重要：「database.history.kafka.topic」：トピックではなく、データベースのShcemaレコード情報を格納します。
- "database.server.name"：データが書き込まれるKafkaトピックのプレフィックス名として、各コネクタの論理名は一意です。
ピット1：変換に関連する5行の構成機能は、データ形式の変換を書き込むことです。
そうでない場合、入力データには、レコード変更の前、後、前、後、比較情報、およびメタデータ情報（source、op、ts_msなど）が含まれます。
この情報は、Elasticsearchへの後続のデータ書き込みでは必要ありません。（独自のビジネスシナリオの組み合わせに注意してください）。
フォーマット変換に関連する原則：http：//t.cn/EftoaIi
5.4コネクタを起動します
1curl -X POST -H "Content-Type:application/json"
2--data @mysql2kafka_debezium.json.json
3http://192.168.1.22:18083/connectors | jq5.5書き込みが成功したことを確認します。
5.5.1kafkaトピックを表示
1 kafka-topics --list --zookeeper localhost:2181ここでは、データトピックに書き込まれた情報が表示されます。
新しく書き込まれたデータトピックの形式に注意してください。database.schema.table-smtは3つの部分で構成されています。
この例のトピック名：
full.kafka_base_db.account-smt
5.5.2消費データ検証の書き込みは正常です
1./kafka-avro-console-consumer --topic full.kafka_base_db.account-smt --bootstrap-server 192.168.1.22:9092 --from-beginningこの時点で、Debeziumはmysql同期kafkaを完了しました。
6、kafka-connectorはkafka同期を実現しますElasticsearch
6.1Kafka-connectorの概要
公式ウェブサイトを参照してください：https：//docs.confluent.io/current/connect.html
Kafka Connectは、Kafkaを外部システム（データベース、キー値ストア、取得システムインデックス、ファイルシステムなど）に接続するためのフレームワークです。
コネクタは、一般的なデータソースデータ（Mysql、Mongo、Pgsqlなど）がKafkaに書き込まれるか、Kafkaデータがターゲットデータベースに書き込まれるか、または独自のコネクタを開発できることを認識します。
6.2、KafkaからESへのコネクタ同期構成
構成パス：
1/home/confluent-5.1.0/etc/kafka-connect-elasticsearch/quickstart-elasticsearch.properties構成内容：
1"connector.class": "io.confluent.connect.elasticsearch.ElasticsearchSinkConnector",
2"tasks.max": "1",
3"topics": "full.kafka_base_db.account-smt",
4"key.ignore": "true",
5"connection.url": "http://192.168.1.22:9200",
6"type.name": "_doc",
7"name": "elasticsearch-sink-test"6.3KafkaからESへの開始コネクタ
開始コマンド
1confluent load elasticsearch-sink-test
2-d /home/confluent-5.1.0/etc/kafka-connect-elasticsearch/quickstart-elasticsearch.properties6.4 Kafka-connctor RESTFulAPIビュー
Mysql2kafkaおよびkafka2ESのコネクタの詳細は、postman、ブラウザ、またはコマンドラインを使用して表示できます。
1curl -X GET http://localhost:8083/connectors7.ピットリプレイ。
ピット2：同期プロセス中にエラーが発生する可能性があります。例：Kafkaトピックはデータを消費できません。
トラブルシューティングのアイデアは次のとおりです。
-
1）消費されたトピックがデータ書き込みのトピックであるかどうかを確認します。
- 2）同期中にエラーがないことを確認します。コネクタを使用して、次のコマンドを表示できます。
1curl -X GET http://localhost:8083/connectors-xxx/statusピット3：Mysql2ESは日付形式を認識しません。
これはMysqljarパッケージの問題です。解決策：my.cnfでタイムゾーン情報を構成します。
ピット4：Kafka2ES、ESはデータを書き込みません。
アイデアのトラブルシューティング：
- 1）提案：最初にトピック名と一致するインデックスを作成します。注：マッピングは静的にカスタマイズされ、動的な識別と生成ではありません。
- 2）コネクタ/ステータスを使用してエラーの原因を分析し、段階的に分析します。
8.まとめ
-
binlogの実現は、フィールドの制限を打ち破ります。実際、業界のgo-mysql-elasticsearchが実装されています。
-
比較：logstash、kafka-connector、Debeziumはリアルタイム同期を実現するための2つのステップを「国を救うための曲線」ですが、安定性+リアルタイムパフォーマンスは比較的良好です。
- みんなに使ってもらいましょう。優れた同期方法がある場合は、メッセージを残して話し合い、交換してください。
参照：
[1] http://t.cn/EftX2p8
[2] http://t.cn/EftXJU6
[3] http://t.cn/EftXO8c
[4] http://t.cn/EftXn9M
[5] http://t.cn/EftXeOc
推奨読書：
Blockbuster | Elasticsearch Methodology Cognitive List（2019 Spring Festival Update）
Elasticsearchの基本、高度、および実際の最初の公開アカウント