Gegevens repliceren in Azure Database for MySQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - Flexibele server

Met replicatie van inkomende gegevens kunt u gegevens van een externe MySQL-server synchroniseren naar een exemplaar van een flexibele Azure Database for MySQL-server. De externe server kan on-premises zijn, in virtuele machines, azure Database for MySQL enkele server of een databaseservice die wordt gehost door andere cloudproviders. Replicatie van gegevens is gebaseerd op de bestandspositie van het binaire logboek (binlog) of op GTID gebaseerde replicatie. Zie de MySQL-replicatie voor meer informatie over binlog-replicatie.

Notitie

Het configureren van inkomende replicatie voor servers waarvoor hoge beschikbaarheid is ingeschakeld, wordt alleen ondersteund via replicatie op basis van GTID.

Wanneer gebruikt u replicatie van inkomende gegevens

De belangrijkste scenario's voor het gebruik van replicatie van inkomende gegevens zijn:

  • Hybride gegevenssynchronisatie: met replicatie van gegevens kunt u gegevens gesynchroniseerd houden tussen uw on-premises servers en flexibele Azure Database for MySQL-server. Deze synchronisatie helpt bij het maken van hybride toepassingen. Deze methode is aantrekkelijk wanneer u een bestaande lokale databaseserver hebt, maar de gegevens naar een regio dichter bij eindgebruikers wilt verplaatsen.
  • Meervoudige cloudsynchronisatie: voor complexe cloudoplossingen gebruikt u replicatie van inkomende gegevens om gegevens te synchroniseren tussen flexibele Azure Database for MySQL-servers en verschillende cloudproviders, waaronder virtuele machines en databaseservices die in deze clouds worden gehost.
  • Migratie: Klanten kunnen in minimale tijd migreren met behulp van opensource-hulpprogramma's zoals MyDumper/MyLoader met in-replicatie van gegevens. Een selectieve cutover van productiebelasting van de bron-naar-doeldatabase is mogelijk met replicatie van gegevens.

Gebruik de Azure Database Migration Service (DMS) voor migratiescenario's.

Beperkingen en overwegingen

Gegevens die niet worden gerepliceerd

De mysql-systeemdatabase op de bronserver wordt niet gerepliceerd. Daarnaast worden wijzigingen in accounts en machtigingen op de bronserver niet gerepliceerd. Als u een account op de bronserver maakt en dit account toegang moet hebben tot de replicaserver, maakt u handmatig hetzelfde account op de replicaserver. Zie de MySQL-handleiding voor meer informatie over de tabellen in de systeemdatabase.

Replicatie van inkomende gegevens wordt ondersteund op servers met hoge beschikbaarheid (HA)

Ondersteuning voor replicatie van inkomende gegevens voor server met hoge beschikbaarheid (HA) is alleen beschikbaar via replicatie op basis van GTID.

De opgeslagen procedure voor replicatie met GTID is beschikbaar op alle servers met hoge beschikbaarheid op basis van de naam mysql.az_replication_change_master_with_gtid.

Filteren

De parameter replicate_wild_ignore_table maakt een replicatiefilter voor tabellen op de replicaserver. Als u deze parameter wilt wijzigen vanuit Azure Portal, gaat u naar het exemplaar van de flexibele Server van Azure Database for MySQL dat wordt gebruikt als replica en selecteert u Serverparameters om de replicate_wild_ignore_table parameter weer te geven of te bewerken.

Vereisten

  • De bronserverversie moet ten minste MySQL versie 5.7 zijn.
  • Onze aanbeveling is om dezelfde versie te hebben voor bron- en replicaserverversies. Beide moeten bijvoorbeeld MySQL versie 5.7 zijn, of beide moeten MySQL versie 8.0 zijn.
  • We raden u aan om een primaire sleutel in elke tabel te hebben. Als we een tabel zonder primaire sleutel hebben, kunt u te maken krijgen met traagheid in de replicatie.
  • De bronserver moet de MySQL InnoDB-engine gebruiken.
  • De gebruiker moet over de juiste machtigingen beschikken om binaire logboekregistratie te configureren en nieuwe gebruikers op de bronserver te maken.
  • Binaire logboekbestanden op de bronserver mogen niet worden opgeschoond voordat de replica deze wijzigingen toepast. Als de bron Azure Database for MySQL flexibele server is, raadpleegt u hoe u binlog_expire_logs_seconds configureert voor flexibele server of enkele server
  • Als SSL is ingeschakeld voor de bronserver, controleert u of het SSL-CA-certificaat dat is opgegeven voor het domein is opgenomen in de mysql.az_replication_change_master opgeslagen procedure. Raadpleeg de volgende voorbeelden en de master_ssl_ca parameter.
  • Zorg ervoor dat de computer die als host fungeert voor de bronserver zowel inkomend als uitgaand verkeer op poort 3306 toestaat.
  • Zorg er bij openbare toegang voor dat de bronserver een openbaar IP-adres heeft, dat DNS openbaar toegankelijk is of dat de bronserver een FQDN (Fully Qualified Domain Name) heeft.
  • Zorg ervoor dat met privétoegang de naam van de bronserver kan worden omgezet en toegankelijk is vanuit het VNet waar het flexibele serverexemplaren van Azure Database for MySQL worden uitgevoerd. (Ga voor meer informatie naar Naamomzetting voor resources in virtuele Azure-netwerken).

Gegenereerde onzichtbare primaire sleutel

Voor MySQL-versie 8.0 en hoger is Gegenereerde onzichtbare primaire sleutels (GIPK) standaard ingeschakeld voor alle exemplaren van flexibele Azure Database for MySQL-servers. MySQL 8.0+-servers voegt de onzichtbare kolom my_row_id toe aan de tabellen en een primaire sleutel in die kolom, waarbij de InnoDB-tabel wordt gemaakt zonder een expliciete primaire sleutel. Deze functie, indien ingeschakeld, kan van invloed zijn op een aantal van de gebruiksscenario's voor replicatie in gegevens, zoals hieronder wordt beschreven:

  • Replicatie van gegevens mislukt met replicatiefout: 'ERROR 1068 (42000): Multiple primary key defined' als de bronserver een primaire sleutel maakt in de tabel zonder primaire sleutel. Voor risicobeperking voert u de volgende SQL-opdracht uit, slaat u de replicatiefout over en start u de replicatie van gegevens opnieuw.

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

  • Replicatie van gegevens mislukt met replicatiefout: FOUT 1075 (42000): Onjuiste tabeldefinitie; er kan slechts één automatische kolom zijn en deze moet worden gedefinieerd als een sleutel" als de bronserver een auto_increment kolom toevoegt als unieke sleutel. Voor risicobeperking voert u de volgende SQL-opdracht uit, stelt u 'sql_generate_invisible_primary_key' in als UIT, slaat u de replicatiefout over en start u de replicatie van gegevens opnieuw.

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

  • Replicatie van inkomende gegevens mislukt als de bronserver andere SQL uitvoert die niet wordt ondersteund wanneer 'sql_generate_invisible_primary_key' is ingeschakeld. Maak bijvoorbeeld een partitietabel. In een dergelijk scenario is het instellen van 'sql_generate_invisible_primary_key' als UIT en het opnieuw opstarten van de replicatie van gegevens.

Volgende stappen