このページは機械翻訳したものです。

6.3.1 InnoDB ReplicaSet の概要

AdminAPI には、InnoDB クラスタ と同様の方法で非同期 GTID ベースレプリケーションを実行する MySQL インスタンスのセットを管理できるようにする InnoDB ReplicaSet のサポートが含まれています。 InnoDB ReplicaSet は、単一のプライマリおよび複数のセカンダリ (従来は MySQL レプリケーションソースおよびレプリカと呼ばれていました) で構成されます。 InnoDB ReplicaSet のステータスを確認したり、障害発生時に新しいプライマリに手動でフェイルオーバーするなど、ReplicaSet オブジェクトおよび AdminAPI 操作を使用して ReplicaSets を管理します。 InnoDB クラスタ と同様に、MySQL Router では InnoDB ReplicaSet に対するブートストラップがサポートされているため、手動で構成しなくても InnoDB ReplicaSet を使用するように MySQL Router を自動的に構成できます。 これにより、InnoDB ReplicaSet は、MySQL レプリケーションおよび MySQL Router を迅速かつ簡単に起動して実行できるため、読取りのスケールアウトに適しており、InnoDB クラスタ で提供される高可用性を必要としないユースケースでは手動フェイルオーバー機能を提供します。

AdminAPI を使用した InnoDB ReplicaSet のデプロイに加えて、既存のレプリケーション設定を採用できます。AdminAPI は、レプリケーション設定のトポロジに基づいて InnoDB ReplicaSet を構成します。 レプリケーション設定が採用されたら、最初からデプロイされた InnoDB ReplicaSet と同じ方法で管理します。 これにより、新しい ReplicaSet を作成せずに、AdminAPI および MySQL Router を利用できます。 詳細は、セクション6.3.4「既存のレプリケーション設定の採用」 を参照してください。

InnoDB ReplicaSet の制限事項

InnoDB ReplicaSet には InnoDB クラスタ と比較していくつかの制限があるため、可能なかぎり InnoDB クラスタ をデプロイすることをお薦めします。 通常、InnoDB ReplicaSet 自体は高可用性を提供しません。 InnoDB ReplicaSet の制限事項は次のとおりです:

• 自動フェイルオーバーは行われません。 プライマリが使用できなくなった場合は、変更を再度行う前に、AdminAPI を使用してフェイルオーバーを手動でトリガーする必要があります。 ただし、セカンダリインスタンスは読取り可能なままです。

• 予期しない停止または使用不可による部分的なデータ損失からの保護はありません。 停止時までにまだ適用されていないトランザクションは失われる可能性があります。

• 予期しない終了または使用不可の後は、不整合から保護しません。 (たとえば、ネットワークパーティションが原因で) 元のプライマリがまだ使用可能な間にフェイルオーバーによってセカンダリが昇格されると、スプリットブレインのために不整合が発生する可能性があります。

• InnoDB ReplicaSet は、マルチプライマリモードをサポートしていません。 すべてのメンバーで書込みが可能なクラシックレプリケーショントポロジでは、データ整合性を保証できません。

• InnoDB ReplicaSet は非同期レプリケーションに基づいているため、読取りスケールアウトが制限されています。そのため、Group Replication の場合とは異なり、フロー制御のチューニングはできません。

• すべてのセカンダリメンバーが単一のソースからレプリケートされます。 一部の特定のシナリオまたはユースケースでは、これがソースに影響する可能性があります。 たとえば、非常に小規模な更新が多数行われています。