sql >> Databáze >  >> RDS >> MariaDB

Migrace sítě s nulovými výpadky s MySQL Galera Cluster pomocí Relay Node

Automatické zřizování uzlů Galera Cluster zjednodušuje složitost škálování databázového clusteru se zaručenou konzistencí dat. SST a IST zlepšují použitelnost počáteční synchronizace dat bez nutnosti ručně zálohovat databázi a kopírovat ji do nového uzlu. Když to zkombinujeme se schopností Galery tolerovat různá nastavení sítě (např. replikaci WAN), můžeme nyní migrovat databázi mezi různými izolovanými sítěmi s nulovým narušením služeb.

V tomto blogovém příspěvku se podíváme na to, jak migrovat náš MySQL Galera Cluster bez prostojů. Přesuneme databázi z Amazon Web Service (AWS) EC2 do Google Cloud Platform (GCP) Compute Engine pomocí přenosového uzlu. Všimněte si, že v minulosti jsme měli podobný příspěvek na blogu, ale tento používá jiný přístup.

Následující diagram zjednodušuje náš plán migrace:

Příprava starého webu

Vzhledem k tomu, že oba weby spolu nemohou komunikovat kvůli bezpečnostní skupině nebo izolaci VPC, potřebujeme mít přenosový uzel, který tyto dva weby přemostí dohromady. Tento uzel může být umístěn na obou stránkách, ale musí být schopen se připojit k jednomu nebo více uzlům na druhé straně na portu 3306 (MySQL), 4444 (SST), 4567 (gcomm) a 4568 (IST). Zde je to, co již máme, a jak změníme měřítko starého webu:

Jako přenosový uzel můžete také použít existující uzel Galera (např. třetí uzel), pokud má připojení na druhou stranu. Nevýhodou je, že kapacita clusteru bude snížena na dvě, protože jeden uzel bude použit pro SST a přenos replikačního streamu Galera mezi lokalitami. V závislosti na velikosti datové sady a spojení mezi lokalitami to může způsobit problémy se spolehlivostí databáze v aktuálním clusteru.

Takže použijeme čtvrtý uzel, abychom snížili riziko na aktuálním produkčním clusteru při synchronizaci na druhou stranu. Nejprve vytvořte novou instanci v AWS Dashboard s veřejnou IP adresou (aby mohla mluvit s vnějším světem) a povolte požadované komunikační porty Galera (TCP 3306, 4444, 4567-4568).

Nasaďte čtvrtý uzel (uzel relé) na starém webu. Pokud používáte ClusterControl, můžete jednoduše použít funkci "Add Node" pro zmenšení clusteru (nezapomeňte předem nastavit SSH bez hesla z uzlu ClusterControl na tento čtvrtý hostitel):

Ujistěte se, že přenosový uzel je synchronizován s aktuálním clusterem a je schopen komunikovat s druhou stranou.

Z nového webu se připojíme k přenosovému uzlu, protože je to jediný uzel, který má konektivitu s vnějším světem.

Nasazení nového webu

Na novém webu nasadíme podobné nastavení s jedním uzlem ClusterControl a tříuzlovým Galera Clusterem. Oba weby musí používat stejnou verzi MySQL. Zde je naše architektura na novém webu:

S ClusterControl je nové nasazení clusteru vzdáleno jen pár kliknutí a je to bezplatná funkce v komunitní edici. Přejděte na ClusterControl -> Deploy Database Cluster -> MySQL Galera a postupujte podle průvodce nasazením:

Klikněte na Nasadit a sledujte průběh v části Aktivita -> Úlohy -> Vytvořit klastr. Po dokončení byste měli mít na řídicím panelu následující:

V tuto chvíli máte dva samostatné seskupení Galera – 4 uzly na starém webu a 3 uzly na novém webu.

Propojení obou stránek

Na novém webu (GCP) vyberte jeden uzel, který bude komunikovat s přenosovým uzlem na starém webu. Jako konektor k reléovému uzlu (galera-aws4) vybereme galera-gcp1. Následující diagram ilustruje náš plán přemostění:

Důležité věci ke konfiguraci jsou následující parametry:

  • wsrep_sst_donor :wsrep_node_name dárcovského uzlu. Na galera-gcp1 nastavte dárce na galera-aws4.
  • wsrep_sst_auth :Pověření uživatele SST ve formátu uživatelské jméno:heslo musí odpovídat starému webu (AWS).
  • wsrep_sst_receive_address :IP adresa, která bude přijímat SST na spojovacím uzlu. Na galera-gcp1 to nastavte na veřejnou IP adresu tohoto uzlu.
  • wsrep_cluster_address :Připojovací řetězec Galera. Na galera-gcp1 přidejte veřejnou IP adresu galera-aws4.
  • wsrep_provider_options :
    • gmcast.segment:Výchozí hodnota je 0. Nastavte jiné celé číslo pro všechny uzly v GCP.
  1. Na přenosovém uzlu (galera-aws4) načtěte wsrep_node_name:

    $ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
    Enter password:
    +-------------------+
    | @@wsrep_node_name |
    +-------------------+
    | 10.0.0.13         |
    +-------------------+
  2. Na my.cnf galera-gcp1 nastavte wsrep_sst_donor hodnotu na předávací uzel wsrep_node_name a wsrep_sst_receive_address na veřejnou IP adresu galera-gcp1:

    wsrep_sst_donor=10.0.0.13
    wsrep_sst_receive_address=35.197.136.232
  3. Na všech uzlech v GCP zajistěte wsrep_sst_auth hodnota je totožná za starým webem (AWS) a změňte segment Galera na 1 (takže Galera ví, že oba weby jsou v různých sítích):

    wsrep_sst_auth=backupuser:mysecretP4ssW0rd
    wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
  4. Na galera-gcp1 nastavte wsrep_cluster_address pro zahrnutí veřejné IP adresy přenosového uzlu:

    wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149

    **Upravte pouze wsrep_cluster_address na galera-gcp1. Tento parametr na galera-gcp2 a galera-gcp3 neupravujte.

  5. Zastavte všechny uzly na GCP. Pokud používáte ClusterControl, přejděte do rozevíracího seznamu Akce clusteru -> Zastavit cluster. Musíte také vypnout automatické obnovení na úrovni clusteru i uzlů, takže ClusterControl se nebude pokoušet obnovit poškozené uzly.

  6. Nyní část synchronizace. Spusťte galera-gcp1. Z protokolu chyb MySQL na donorovém uzlu můžete vidět, že SST je iniciováno mezi přenosovým uzlem (10.0.0.13) pomocí veřejné adresy na galera-gcp1 (35.197.136.232):

    2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
    ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
    2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
            2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
    2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

    Vezměte na vědomí, že v tomto okamžiku bude galera-gcp1 zaplavena následujícími řádky:

    2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
    2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
    2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

    Toto varování můžete bezpečně ignorovat, protože galera-gcp1 se neustále snaží vidět zbývající uzly za přenosovým uzlem na AWS.

  7. Po dokončení SST na galera-gcp1 nebude ClusterControl na GCE schopen připojit databázové uzly kvůli chybějícím GRANTům (stávající GRANTy byly po synchronizaci z AWS přepsány). Zde je to, co musíme udělat po dokončení SST na galera-gcp1:

    mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;

    Jakmile to uděláte, ClusterControl bude správně hlásit stav galera-gcp1, jak je zvýrazněno níže:

  8. Poslední částí je spuštění zbývajících galera-gcp2 a galera-gcp3, jeden uzel po druhém. Přejděte do ClusterControl -> Nodes -> vyberte uzel -> Start Node. Jakmile jsou všechny uzly synchronizovány, měli byste získat 7 jako velikost clusteru:

Cluster nyní funguje na obou lokalitách a škálování je dokončeno.

Vyřazení z provozu

Jakmile bude migrace dokončena a všechny uzly budou synchronizovány, můžete svou aplikaci začít přepínat na nový cluster na GCP:

V tomto okamžiku jsou data MySQL replikována do všech uzlů až do vyřazení z provozu. Výkon replikace bude tak dobrý, jak to dovolí nejvzdálenější uzel v clusteru. Přenosový uzel je kritický, protože vysílá sady zápisu na druhou stranu. Z hlediska aplikace se doporučuje zapisovat vždy pouze na jeden web, což znamená, že budete muset začít přesměrovávat čtení/zápisy z AWS a místo toho je obsluhovat z clusteru GCP.

Abychom vyřadili staré databázové uzly a přesunuli se do clusteru na GCP, musíme provést elegantní vypnutí (po jednom) na AWS. Je důležité uzly elegantně vypnout, protože web AWS obsahuje většinu uzlů (4/7) pro tento cluster. Jejich vypnutí všech najednou způsobí, že cluster na GCP přejde do neprimárního stavu, což přinutí cluster odmítnout operaci. Ujistěte se, že poslední uzel k vypnutí na straně AWS je přenosový uzel.

Nezapomeňte odpovídajícím způsobem aktualizovat následující parametry na galera-gcp1:

  • wsrep_cluster_address - Odeberte veřejnou IP adresu přenosového uzlu.
  • wsrep_sst_donor - Komentujte tento řádek. Nechte Galera, aby vybrala dárce.
  • wsrep_sst_receive_address - Komentujte tento řádek. Nechte aplikaci Galera automaticky vybrat přijímací rozhraní.

Váš Galera Cluster nyní běží na zcela nové platformě, hostitelích a síti bez vteřiny výpadku vaší databázové služby během migrace. Jak skvělé to je?


  1. Count(*) vs Count(1) - SQL Server

  2. Jak převést čas na časové pásmo zařízení iPhone?

  3. Oracle Security Alert pro CVE-2021-44228

  4. Vygenerujte sadu nebo sekvenci bez smyček – část 2