オープンソースで無償利用｜Apache Doris 2.0、クラスタ間データレプリケーション機能を開始

エンタープライズビジネスの発展に伴い、システムアーキテクチャは複雑化する傾向にあり、データ規模は増大の一途をたどっており、データは異なる地域やデータセンター、クラウドプラットフォームに分散して保管されることが多くなっています。データの量とオンライン サービスの継続性が人々の注目を集めています。これに基づいて、時代の要求に応じてクラスタ間レプリケーション (CCR) が登場し、徐々にデータとサービスの高可用性を保証する重要なものになってきました。

CCR は通常、災害復旧バックアップ、読み取りと書き込みの分離、グループや企業間のデータ送信、分離アップグレードなどのシナリオで使用されます。

• ディザスタリカバリバックアップ: 通常、企業のデータは別のクラスタやコンピュータルームにバックアップされますが、緊急事態により業務が中断または損失された場合、バックアップからデータを復元したり、マスターとバックアップを迅速に切り替えたりすることができます。一般に、災害復旧バックアップは、金融、医療、電子商取引、その他の分野など、高い SLA 要件が求められるシナリオで必要となります。

• 読み取りと書き込みの分離: 読み取りと書き込みの分離は、データ クエリ操作と書き込み操作を分離することです。その目的は、読み取り操作と書き込み操作の相互影響を軽減し、リソースの使用率を向上させることです。たとえば、データベースの書き込みプレッシャーが高すぎる場合、または同時実行性の高いシナリオでは、読み取りと書き込みの分離を使用して、読み取り/書き込み操作を複数のリージョンの読み取り専用/書き込み専用データベースのケースに分散し、相互の影響を軽減できます。読み取りと書き込みの間で効率的にデータベースのパフォーマンスと安定性を確保します。

• グループと支社間のデータ送信：グループ内のデータを一元管理、制御、分析するために、通常、グループ本社からグループ本社へのデータ送信を、各地に分散した支社からタイムリーに同期する必要があります。データの不整合による経営の混乱や意思決定を避けるために、各地域での管理を徹底しています。 間違いはグループの経営効率や意思決定の質の向上につながります。

• 分離アップグレード: システム クラスターをアップグレードする場合、何らかの理由でバージョンをロールバックする必要がある場合があります。メタデータの非互換性のため、従来のアップグレード モードは多くの場合ロールバックできません。CCR を使用すると、この問題を解決できます。まずアップグレードと二重実行検証用に予備のクラスタを構築します。ユーザーは各クラスタを順番にアップグレードできます。同時に、CCR は特定のバージョンに依存しないため、バージョンのロールバックが可能です。

上記のシナリオのニーズを満たすために、市場の多くのデータ製品には CCR 機能が導入されており、その中でも Elasticsearch と ClickHouse が代表的です。

• CCRはElasticsearchが提供する有料機能で、本質的にはリーダー/フォロワーの同期ですが、データをインポートする際に、書き込まれたデータではなくパーティションごとにデータを同期するため、データの不整合が発生します。

• ClickHouse は通常、リモート機能または ClickHouse-Copier を通じて CCR を実装します。リモート関数は、同期のためにテーブルとパーティションを走査する必要がある完全同期にのみ適しています。ClickHouse-Copie は増分移行もサポートしていません。ClickHouse 自体にはトランザクション設計がないため、Copier を使用してデータを同期することは、クロスレベル グループ間のレプリカ同期と同等です。同期の一貫性は保証できず、DB レベルでの同期は保証できません。表に従って 1 つずつ設定する必要があり、使用プロセスは比較的複雑ですが、使いやすさは平均的です。

CCR はシステムサービスの可用性の点で企業からの要望が強いため、多くのメーカーが製品の有料付加価値機能に CCR を組み込んでおり、使用するにはエンタープライズ版を購入する必要があります。 オープンソースとオープン性の原則に従い、大多数のオープンソース ユーザーにサービスを提供するために、 Apache Dorisバージョン 2.0 で CCR を正式に開始しました。

Elasticsearch や Clickhouse と比較して、Apache Doris CCR はソース クラスターのデータ変更をライブラリ/テーブル レベルでターゲット クラスターに同期でき、シナリオに応じて同期範囲を細かく制御でき、ユーザーは完全同期または増分同期を柔軟に選択することもできます。データ同期の柔軟性と効率が向上します。さらに、Doris CCR は DDL 同期もサポートしており、ソース クラスターによって実行される DDL ステートメントをターゲット クラスターに自動的に同期できるため、データの一貫性が確保されます。Doris CCR は設定と使用が非常に簡単で、簡単な操作でクラスタ間のデータ レプリケーションを迅速に完了できます。Doris CCR の優れた機能に基づいて、読み取り/書き込み負荷の分離と複数のコンピューター ルームのバックアップをより適切に実現し、さまざまなシナリオでのクラスター間のレプリケーション要件をより適切にサポートできます。

ドリス CCR の設計

Apache Doris バージョン 2.0 では、Meta Binlog や Data Binlog などのデータ変更レコードを追跡するための Binlog メカニズムが導入されました。クラスター間のデータ同期を実現するために、外部コンポーネント Syncer を導入し、Syncer を通じて最新の Binlog を取得し、それをダウンストリーム クラスターに再生してデータ同期を実現しました。冗長な Binlog を起動します。具体的な実装には次のものが含まれます。

ビンログの追加

Apache Doris 2.0 より前のバージョンでは、Apache Doris データ変更レコードを追跡できず、データ変更レコードは CCR 実装の事前依存関係でした。この問題を解決するために、Apache Doris 2.0ではBinlog機構を導入し、Binlog機構によりデータの変更記録や操作を自動的に記録することでデータのトレーサビリティを実現するとともに、Binlog再生機構によるデータ再生も実現しました。 . を入れて復元します。データベースのテーブルレベルの同期をサポートしているため、使用する場合はDB/TableにBinlog関連の属性を追加する必要がありますが、現在Binlogはenableとttl_秒をサポートしています。

注: CCR 機能を使用する場合は、Binlog を有効にすることが必須の前提条件です。

-- Table
alter table binlog set ("binlog.enable" = "true"); //开启 binlog
alter table binlog set ("binlog.ttl_seconds" = "864000"); // 配置 binlog 过期时间

-- DB
alter database ccr set properties ("binlog.enable" = "true");
alter database ccr set properties ("binlog.ttls" = "864000");

永続化メカニズム

システムクラッシュやさまざまな緊急事態の後にタイムリーな回復を確実にするために、データの信頼性と一貫性を確保するためにデータをディスクに永続化する永続化メカニズムを導入しました。データの永続化には主に、FE によって保存されるメタデータ情報と BE によって保存される実際のデータ自体が含まれます。Binlog 属性を有効にした後、FE と BE は DDL/DML 操作の変更レコードを Meta Binlog と Data Binlog に永続化します。データ操作を実行すると、FE は対応するログ レコードをトリガーします。ログの順序を確実にするために EditLog 実装を強化しました。LogID の増加シーケンスを構築することにより、各操作が正確に記録され、順番に保持されます。この順序付けされた永続化メカニズムは、データの一貫性を確保するのに役立ちます。

FE がパブリッシュ トランザクションを開始すると、BE は対応するパブリッシュ操作を実行し、BE は Rowet_meta というプレフィックスが付いた KV に Rowset を含むこのトランザクションのメタデータ情報を書き込み、それをメタ ストレージに永続化します。ビンログフォルダー。このようにして、FE のメタデータと BE のデータは論理的な Binlog シリーズを構築できます。この仕組みは、物理ファイル再生または論理再生によるデータ復旧を実現し、パフォーマンスと信頼性の点で効果的なソリューションを提供します。

データ再生

ソース クラスターとターゲット クラスターをより適切に接続するために、中間同期および制御コンポーネントである Syncer を導入しました。Syncer を通じて、ソース クラスターのデータをターゲット クラスターに抽出し、Binlog シリーズを別のクラスターに抽出してデータを再生できます。

実装：

• 物理ファイル再生をサポートし、物理ファイル再生方法を使用して、データ操作プロセスを効果的に再現できます。

• Syncer は、FE CommitSeq をカーソルとして使用して、次のコミットのメタ ビンログを取得します。Syncer は、ダウンストリーム BE をアップストリーム BE に調整して、メタ ビンログ情報に従って実際のビンログ ファイルを抽出します。このメカニズムにより、再生データの一貫性が保証されるだけでなく、効率的なデータ同期パフォーマンスも保証されます。

• 同期を処理するとき、Syncer はタスクの作成時に最初にスナップショット レベルのバックアップ/復元を使用して Doris 上で完全なデータ リカバリを実行し、次に復元されたスナップショットの CommitSeq に基づいて増分データ リカバリを実行します。

ビンログデータのクリーニング

インポートされるデータが増えるにつれて、Binlog によって記録されるデータ操作も増え、占有されるストレージ リソースが徐々に増加します。したがって、冗長な Binlog をクリーンアップするデータ リサイクル メカニズムが必要です。

Binlog データをクリーンアップする場合、Binlog GC を構成する際には、DB とテーブルの Binlog GC の同期状態に注意する必要があります。たとえば、ユーザーが DB Binlog を有効にする前に Table Binlog を有効にし、その後 DB Binlog を無効にした場合、DB のクリーニング条件が Table のクリーニング条件よりも優先されるため、以前の Table Binlog Enable 状態の関連構成を維持する必要があります。 Binlog が Enable ステータスの場合、DB の GC 時間に従って Binlog をクリーンアップする必要があります。そうしないと、DB と Table のクリーンアップ ステータスが不一致になり、Binlog の不一致につながります。

この状況に直面すると、FE 側は、Binlog の有効期限に従って期限切れの Binlog を定期的にスキャンし、対応するクリーンアップ有効期限リクエストを BE に送信し、BE は最後のコミット シーケンスに従って、対応するタブレット上でメタデータと Rowset を実行します。ビンログの掃除。この際、DBとTable Binlogの重複に注意する必要があります。

CCRの使い方

規約と条件

現時点では、CCRを使用する場合、一時的にDorisのRoot権限を有効にする必要があります。その他の注意点は以下のとおりです。

• ソース クラスターの Binlog プロセスにはマスター トークンが必要であり、マスター トークンには FE で取得するための Root 権限が必要です。

• メタクラスターへの他の Binlog 取得の場合は、表示権限のみが必要です

• Binlog 自体の同期には、テーブルまたは DB のターゲット クラスターでロード権限を有効にするだけで済みます。

インストールと展開

1. ソース クラスターとターゲット Doris クラスターをデプロイします。

2. データ同期コンポーネント Syncer をデプロイする

ソースコードをダウンロードしてコンパイルする

git clone https://github.com/selectdb/ccr-syncer
cd ccr-syncer

# -j 开启多线程编译
# --output指定输出的路径名称，默认名称为output
bash build.sh <-j NUM_OF_THREAD> <--output SYNCER_OUTPUT_DIR>

コンパイルされたソース コードは Doris と同様に Output フォルダーにあり、開始/停止スクリプトは Bin に、実行可能ファイルは Lib にあります。

# SYNCER_OUTPUT_DIR是编译的输出路径
# SYNCER_DEPLOY_DIR是实际部署的路径
cp -r SYNCER_OUTPUT_DIR SYNCER_DEPLOY_DIR
cd SYNCER_DEPLOY_DIR

# 启动syncer，加上--daemon使syncer在后台运行
bash bin/start_syncer.sh --daemon

# 停止syncer
bash bin/stop_syncer.sh

構成タスク

1. FE/BE の conf ファイルに次の設定を追加して、Binlog を有効にします。

enable_feature_binlog=true

2. ターゲットクラスター内の同期ライブラリ/テーブルのバイナリログを開きます。

-- enable database binlog
ALTER DATABASE ccr SET properties ("binlog.enable" = "true");

-- enable table binlog
ALTER TABLE enable_binlog SET ("binlog.enable" = "true");

3. Syncer への同期タスクを開始する

curl -X POST -H "Content-Type: application/json" -d '{
    "name": "ccr_test",
    "src": {
      "host": "localhost",
      "port": "9030",
      "thrift_port": "9020",
      "user": "root",
      "password": "",
      "database": "demo",
      "table": "example_tbl"
    },
    "dest": {
      "host": "localhost",
      "port": "9030",
      "thrift_port": "9020",
      "user": "root",
      "password": "",
      "database": "ccrt",
      "table": "copy"
    }
}' http://127.0.0.1:9190/create_ccr

補足パラメータの説明:

• name: CCR 同期タスクの名前 (一意のみ)

• ホスト、ポート: クラスターマスターのホストおよび MySQL (JDBC) のポートに対応します。

• thrift_port: FEに対応するrpc_port

• ユーザー、パスワード: Syncer がトランザクションのオープンやデータのプルなどに使用する ID を示します。

• データベース、テーブル：

  • ライブラリレベルでの同期の場合、dbName と tableName は空になります。

  • テーブルレベルの同期の場合は、空ではなく dbName、tableName を入力する必要があります。

ステータスの表示とキャンセル

1. 同期の進行状況を表示する

curl -X POST -H "Content-Type: application/json" -d '{
    "name": "ccr_test"
}' http://127.0.0.1:9190/get_lag

2. タスクを停止する

curl -X POST -H "Content-Type: application/json" -d '{
    "name": "ccr_test"
}' http://127.0.0.1:9190/stop_ccr

データ同期性能測定

CCRのデータ同期効率をテストするために、全量データに基づくインポートテストも実施しました。全量データのインポートプロセス中、2TBのデータを4時間以内に同期でき、単一ノードの書き込み速度は170MB/秒を超え、具体的な結果は以下の表に示されています。クラスタ規模が拡大するにつれて、データ書き込みの効率は直線的に増加します。

パフォーマンス テストは特定の環境と構成でテストされており、結果はさまざまな環境、バージョン、構成に関連するため、参考のみであることに注意してください。

完全同期

ソース クラスタとターゲット クラスタは両方とも 1FE 1BE クラスタであり、システム情報とハードウェア情報は次のとおりです。

ソースクラスターのデータボリューム: 2097152MB

対象クラスタのデータ量：0

完全同期パフォーマンステストの結果

その後の計画

現在、Doris CCR はテーブルおよびライブラリ レベルのデータ同期をすでにサポートしています。具体的には、テーブル レベルでのさまざまなデータ インポート方法をサポートし、単一テーブルのマテリアライズド ビューの追加などの軽量および重量のスキーマ変更をサポートして、より柔軟なデータ同期要件をサポートします。同時に、CCR は動的パーティショニングもサポートし、手動パーティショニングは データベース全体の同期はデータベース レベルでサポートされており、ソース クラスタ内のすべてのテーブル データをターゲット クラスタに同期できます。さらに、CCR はテーブルの作成と削除の同期操作もサポートしており、ソース クラスターでテーブルを作成または削除すると、ターゲット クラスターに自動的に同期され、データの同期と整合性が実現されます。

今後も、Doris CCR の同期能力とパフォーマンスを継続的に改善するために、主に次のような取り組みを続けていきます。

• データベース レベルでの DDL 操作をさらに強化し、より柔軟で信頼性の高いデータ同期および管理機能を提供します。

• ユーザー定義の Binlog 消費をサポートし、Select ステートメントを直接使用して Binlog を消費し、MySQL プロトコルの Rowset などの対応するドライバーに従ってデータを返します。

• 論理データ形式の同期をサポートし、ユーザーがターゲット クラスタ BE をソース クラスタ BE に移動させて、CSV や Parquet などの標準形式で増分データ (Binlog) を取得できるようにします。これは、基礎となる複数の互換性のないバージョン間で同期するのに便利です。 BE データ形式 (行セット) ;

• ホットとコールドの分離をサポートし、Doris 独自の階層ストレージのサポートを改善します。

• ライブラリレベルの同期はブラックリストをサポートしており、その目的は特定のテーブルをフィルタリングすることです。ライブラリ内の一部のテーブルは同期する必要がないため、ユーザーは各テーブルに個別の同期タスクを設定せずに CCR を簡単に使用できます (複数のテーブルを確実に同期するのに便利です)その上）

• ターゲット クラスターはアクティブ/スタンバイの切り替えをサポートしており、Binlog を有効にすると増分データをソース クラスターに同期できます。

• Syncer の運用と保守および可観測性関連の機能を強化し、Syncer の運用と保守の展開機能を改善し、Syncer のオーバーヘッドと同期タスクの進行状況を監視します。これにより、Syncer は、より関連した運用および保守操作、分散展開および同期の進行状況のサポート、およびさまざまな DB のサポートをサポートできるようになります。

関連するニーズがある学生は、コメント領域でニーズや質問を積極的にフィードバックすることもできます。

＃ 著者について：

Xu Ruiliang 氏、SelectDBシニア R&D エンジニア

Li Shiyang 氏、SelectDB の生態学研究開発エンジニア