次の方法で共有

データを Azure Database for MySQL にレプリケートする - フレキシブル サーバー

  • [アーティクル]

データイン レプリケーションでは、外部の MySQL サーバーから Azure Database for MySQL フレキシブル サーバー インスタンスにデータを同期できます。 外部サーバーとして、オンプレミス、仮想マシン内、Azure Database for MySQL Single Server、または他のクラウド プロバイダーによってホストされるデータベース サービスを使用できます。 データイン レプリケーションは、バイナリ ログ (binlog) ファイル位置ベースまたは GTID ベースのレプリケーションに基づいています。 binlog レプリケーションの詳細については、MySQL レプリケーションに関するページを参照してください。

Note

高可用性対応サーバーでのデータイン レプリケーションの構成は、GTID ベースのレプリケーションのみでサポートされています。

いつデータイン レプリケーションを使用するか

データイン レプリケーションの使用を検討する主なシナリオは次のとおりです。

  • ハイブリッド データ同期: データイン レプリケーションを使用して、オンプレミス サーバーと Azure Database for MySQL フレキシブル サーバー間のデータの同期を維持できます。 この同期は、ハイブリッド アプリケーションの作成に役立ちます。 この方法は、既存のローカル データベース サーバーがあるが、エンドユーザーに近いリージョンにデータを移動する場合に魅力的です。
  • 複数のクラウドの同期: 複雑なクラウド ソリューションでは、データイン レプリケーションを使用して、Azure Database for MySQL フレキシブル サーバー と、別のクラウド プロバイダー 間でデータを同期します (これらのクラウドでホストされている仮想マシンとデータベース サービスが含まれます)。
  • 移行: お客様は、MyDumper/MyLoader などのオープン ソース ツールとデータイン レプリケーションを使用して、最小限の時間で移行できます。 データイン レプリケーションでは、ソースデータベースから宛先データベースへの実稼働負荷の選択的なカットオーバーが可能です。

移行シナリオについては、Azure Database Migration Service (DMS) を使用してください。

制限と考慮事項

レプリケートされないデータ

ソース サーバー上の "mysql システム データベース" はレプリケートされません。 さらに、ソース サーバーでのアカウントとアクセス許可の変更はレプリケートされません。 ソース サーバー上にアカウントを作成し、このアカウントでレプリカ サーバーにアクセスする必要がある場合は、レプリカ サーバー上に同じアカウントを手動で作成します。 システム データベースのテーブルを理解するには、MySQL のマニュアルを参照してください。

高可用性 (HA) 対応のサーバーで、データイン レプリケーションはサポートされています

高可用性 (HA) 対応サーバーのデータイン レプリケーションのサポートは、GTID ベースのレプリケーションでのみ使用できます。

GTID を使用したレプリケーションのストアド プロシージャは、mysql.az_replication_change_master_with_gtid という名前ですべての HA 対応サーバーで使用できます。

フィルター

パラメーター replicate_wild_ignore_table は、レプリカ サーバー上のテーブルのレプリケーション フィルターを作成します。 Azure portal からこのパラメーターを変更するには、レプリカとして使用する Azure Database for MySQL フレキシブル サーバー インスタンスに移動し、[サーバー パラメーター] を選択して、replicate_wild_ignore_table パラメーターを表示または編集します。

必要条件

  • ソース サーバーのバージョンは、MySQL バージョン 5.7 以上である必要があります。

  • ソース サーバーとレプリカ サーバーのバージョンに対して同じバージョンを使用する方法をお勧めしています。 たとえば、両方が MySQL 5.7 バージョンであるか、両方が MySQL バージョン 8.0 である必要があります。

  • 各テーブルに主キーを含めることを推奨します。 主キーのないテーブルがある場合は、レプリケーションの速度が低下する可能性があります。

  • ソース サーバーでは、MySQL InnoDB エンジンを使用する必要があります。

  • ユーザーは、バイナリ ログの構成とソース サーバーでの新しいユーザーの作成を実行できる適切なアクセス許可を持っている必要があります。

  • レプリカがこれらの変更を適用する前に、ソース サーバー上のバイナリ ログ ファイルを削除しないでください。 ソースが Azure Database for MySQL フレキシブル サーバーの場合、「フレキシブル サーバーまたは単一サーバーの binlog_expire_logs_seconds を構成する方法」を参照してください

  • ソース サーバーで SSL が有効になっている場合は、ドメインに対して指定されている SSL CA 証明書が mysql.az_replication_change_master ストアド プロシージャに含まれていることを確認します。 次の例と master_ssl_ca パラメーターを参照してください。

  • ソース サーバーをホストしているマシンのポート 3306 で受信と送信の両方のトラフィックが許可されていることを確認します。

  • パブリック アクセスでは、ソース サーバーにパブリック IP アドレスがあること、DNS がパブリックにアクセス可能であること、またはソース サーバーに完全修飾ドメイン名 (FQDN) があることを確保します。 プライベート エンドポイントがあるとき、パブリック アクセスを向こうにしている場合、データイン レプリケーションはサポートされません

  • プライベート アクセス (VNET 統合) では、ソース サーバー名を解決できることと、Azure Database for MySQL フレキシブル サーバー インスタンスが実行されている VNet からアクセスできることを確保します。 (詳細については、「Azure 仮想ネットワーク内のリソースの名前解決の設定」にアクセスしてください)。

生成された非表示の主キー

MySQL バージョン 8.0 以降では、すべての Azure Database for MySQL フレキシブル サーバー インスタンスに対して、生成された非表示の主キー (GIPK) が既定で有効になっています。 MySQL 8.0 以降のサーバーでは、非表示の列 my_row_id がテーブルに追加され、その列で主キーが追加されます。InnoDB テーブルは明示的な主キーなしで作成されます。 この機能を有効にすると、以下で説明するように、データイン レプリケーションの一部のユース ケースに影響することがあります。

  • 主キーなしのテーブル上でソース サーバーによって主キーが作成されると、「エラー 1068 (42000): 複数の主キーが定義されています」というレプリケーション エラーでデータイン レプリケーションが失敗します。 軽減策としては、次の SQL コマンドを実行し、レプリケーション エラーをスキップし、データイン レプリケーションを再実行します。

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • ソース サーバーによって auto_increment 列が一意のキーとして追加されるとき、「エラー 1075 (42000): 不適切なテーブル定義。自動列は 1 つだけにし、キーとして定義する必要があります」というレプリケーション エラーでデータイン レプリケーションが失敗します。 軽減策としては、次の SQL を実行し、"sql_generate_invisible_primary_key" を OFF に設定し、レプリケーション エラーをスキップし、データイン レプリケーションを再実行します。

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • "sql_generate_invisible_primary_key" が ON になっていると、サポートされていないその他の SQL をソース サーバーで実行した場合、データイン レプリケーションが失敗します。 たとえば、パーティション テーブルを作成します。 このようなシナリオでは、"sql_generate_invisible_primary_key" を OFF に設定し、データイン レプリケーションを再実行します。

関連するコンテンツ