テーブルの複製とは、OceanBaseデータベースにおける特殊なテーブルの一種です。このようなテーブルでは、任意の「正常」なレプリカ上でデータの最新の変更を読み取ることができます。書き込み頻度が低く、読み取り操作の遅延やロードバランシングに対する要求が高いユーザーにとって、テーブルの複製は理想的な選択肢となります。
テーブルの複製とは
テーブルの複製と通常のテーブルとの主な違いは、読み取りレプリカが最新データの読み取りをサポートするかどうかにあります。通常のテーブルのレプリカは弱い整合性の読み取りリクエストのみを実行し、古いバージョンのデータを読み取ります。一方、テーブルの複製のレプリカは強い整合性の読み取りをサポートし、最新バージョンのデータを読み取ることができます。
ユーザーがテーブルの複製を作成すると、現在のテナントのすべてのOBServerノード上にその複製のレプリカが作成されます。その中で、1つのレプリカがリーダーとして選ばれ、書き込みリクエストを受け付ける役割を担い、残りのレプリカは読み取りリクエストのみを受け付けることができます。
すべてのレプリカはリーダーに対して状態を報告する必要があり、主にレプリカの再生進捗、つまりデータ同期の進捗を報告します。通常、フォロワーの再生進捗はリーダーよりも若干遅れますが、その遅れが一定のしきい値を超えない限り、リーダーはレプリカを「正常」な状態と判断し、リーダー上の変更を迅速に再生できると見なします。リーダーが特定のレプリカが一定期間「正常」な状態を維持したと判断すると、フォロワーに一定期間のリースを付与します。簡単に言えば、リーダーは今後の一定期間、フォロワーが「正常」な状態を維持し、強い整合性の読み取りサービスを提供できると「信頼」します。この「信頼」期間中、リーダーはテーブルの複製トランザクションをコミットするたびに、フォロワーの再生進捗を確認します。フォロワーがそのトランザクションの変更を再生した後にのみ、リーダーはユーザーにトランザクションのコミット成功を報告します。この場合、ユーザーは「正常」なフォロワー上で、ちょうどコミットされたトランザクションの変更を読み取ることができます。ただし、そのフォロワーの再生進捗がトランザクションコミット時の状態に追いついていることが前提です。
なぜテーブルの複製が必要なのか
「1書き込み・複数読み取り」というのは、データベースにおいてよく見られるデプロイメント方式の一つであり、1つのノードがすべての書き込み操作を処理し、その後ロジックログを非同期で他の読み取りノード（例えばAmazon Auroraなど）に同期します。このデプロイメント方式の利点は、読み取り負荷を複数のノードに分散させることで、災害復旧能力を向上させることができる点にあります。また、クライアントから物理的に近いノードほど、読み取りの遅延が低くなります。
OceanBaseでは、通常、弱い整合性の読み取りと複数レプリカを組み合わせた方式でこのニーズを実現しています。その中で、1つのレプリカ（リーダー）が書き込みサービスと即時の強い整合性の読み取りを提供し、他のフォロワーはより古いコミット済みデータを読み取ることができます。弱い整合性の読み取りは、非同期複製のデータ同期方式において一般的な選択肢であり、リーダーは書き込み時にフォロワーのデータ再生進捗を気にする必要がなく、フォロワーは一貫した古いバージョンのデータ読み取りを提供できます。
しかし、一部のシナリオでは、ユーザーの書き込み頻度が非常に低く、書き込み操作の遅延にはそれほど敏感ではありません。相対的に、これらのユーザーは読み取り操作の遅延やロードバランシングにより関心が高く、最新データを迅速に読み取ることを望んでいます。テーブルの複製機能は、このようなニーズを満たすために設計されており、少数のトランザクションコミット性能を犠牲にすることで、任意の「正常」なフォロワー上で最新データを読み取ることができます。ここで言う「正常」とは、フォロワーとリーダー間のネットワークがスムーズで、再生進捗の差が大きくないことを指します。
V3.x系とV4.x系におけるテーブルの複製の違い
テーブルの複製機能は、OceanBaseデータベースのV3.x系でも既に存在していましたが、V4.x系ではOceanBaseデータベースのアーキテクチャが大幅に変更されたため、V4.x系のテーブルの複製はスタンドアロンログストリームの新しいアーキテクチャに適応し、パーティションに基づく読み取り可能バージョン番号の検証やログストリームに基づくリース付与メカニズムを導入し、強い整合性の読み取りの正確性を保証しています。
さらに、V4.x系のテーブルの複製機能では、プライマリ切り替え時にトランザクションを終了しない機能が強化されました。ユーザーまたはロードバランシングがリーダー切り替えを開始する際、コミットされていないテーブルの複製トランザクションは、V3.x系のように継続できなくなることはなく、プライマリ切り替え後も引き続き実行可能です。V3.x系と比較して、V4.x系のテーブルの複製機能は、書き込みトランザクションの性能と災害復旧能力の両面で向上しており、レプリカのダウンが読み取り操作へ与える影響も低くなっています。