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

  • [アーティクル]

適用対象: Azure Database for MySQL - フレキシブル サーバー

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

Note

GTID ベースのレプリケーションは、現在、Azure Database for MySQL - フレキシブル サーバーでサポートされていません。
ゾーン冗長高可用性サーバーでのデータイン レプリケーションの構成は、サポートされていません。

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

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

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

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

制限と考慮事項

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

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

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

高可用性 (HA) オプションが有効になっているサーバーに対してデータイン レプリケーションを構成することはサポートされていません。 HA が有効であるサーバーでは、レプリケーション mysql.az_replication_* のストアド プロシージャを利用できません。

ヒント

HA サーバーをソース サーバーとして使用している場合、サーバーでフェールオーバーが発生すると、MySQL ネイティブ バイナリ ログ (binlog) ファイルの位置ベースのレプリケーションが失敗します。 レプリカ サーバーで GTID ベースのレプリケーションがサポートされている場合は、GTID ベースのレプリケーションを構成する必要があります。

フィルター

パラメーター 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) があることを確認します。
  • パブリック アクセスでは、ソース サーバーにパブリック IP アドレスがあり、DNS がパブリックにアクセス可能であり、またはソース サーバーに完全修飾ドメイン名 (FQDN) があることを確保します。
  • プライベート アクセスでは、ソース サーバー名を解決できることと、Azure Database for MySQL インスタンスが実行されている VNet からアクセスできることを確保します。 (詳細については、「Azure 仮想ネットワーク内のリソースの名前解決の設定」にアクセスしてください)。

次のステップ