Migrace databáze do nového datového centra může být vysoce rizikový a časově náročný proces. Databáze obsahuje stav a může být mnohem obtížnější ji migrovat ve srovnání s webovými servery, frontami nebo cache servery.
V tomto příspěvku na blogu vám poskytneme několik tipů, jak migrovat data od jednoho poskytovatele služeb k druhému. Proces je do jisté míry podobný našemu předchozímu příspěvku o upgradu MySQL, ale je zde několik důležitých rozdílů.
Replikace MySQL nebo Galera Cluster?
Přechod k jinému poskytovateli služeb (např. přechod z AWS do Rackspace nebo ze sdílených serverů do cloudu) velmi často znamená, že by člověk paralelně vybudoval zcela novou infrastrukturu, synchronizoval ji se starou infrastrukturou a poté na ni přešel. Chcete-li je připojit a synchronizovat, možná budete chtít využít replikaci MySQL.
Pokud používáte Galera Cluster, může být jednodušší přesunout uzly Galera do jiného datového centra. Všimněte si však, že s celým clusterem je stále třeba zacházet jako s jednou databází. To znamená, že vaše produkční místo může trpět dodatečnou latencí zavedenou při roztahování Galera Cluster přes WAN. Dopad je možné minimalizovat vyladěním síťových nastavení v Galeře i operačním systému, ale dopad nelze zcela eliminovat. Je také možné místo toho nastavit asynchronní replikaci MySQL mezi starým a novým clusterem, pokud dopad latence není přijatelný.
Nastavení zabezpečeného připojení
Replikace MySQL je nešifrovaná, a proto není bezpečné ji používat přes WAN. Existuje mnoho způsobů, jak zajistit bezpečný přenos vašich dat. Měli byste prozkoumat, zda je možné vytvořit připojení VPN mezi vaší stávající infrastrukturou a vaším novým poskytovatelem služeb. Většina poskytovatelů (například Rackspace i AWS) takovou službu poskytuje – svou „zamračenou“ část můžete připojit ke stávajícímu datovému centru prostřednictvím virtuální privátní sítě.
Pokud vám z nějakého důvodu toto řešení nefunguje (možná vyžaduje hardware, ke kterému nemáte přístup), můžete k vybudování VPN použít software – jedním z nich bude OpenVPN. Tento nástroj bude dobře fungovat pro nastavení šifrovaných spojení mezi vašimi datovými centry.
Pokud OpenVPN není možnost, existuje více způsobů, jak zajistit, aby replikace byla šifrována. Můžete například použít SSH k vytvoření tunelu mezi starými a novými datovými centry a předat port 3306 z aktuálního MySQL slave (nebo masteru) do nového uzlu. Lze to provést velmi jednoduchým způsobem, pokud máte mezi hostiteli připojení SSH:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Například:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Nyní se můžete připojit ke vzdálenému serveru pomocí 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Pro replikaci to bude fungovat podobně, jen nezapomeňte použít 127.0.0.1 pro master_host a 3307 pro master_port
V neposlední řadě můžete svou replikaci zašifrovat pomocí SSL. Tento předchozí příspěvek na blogu vysvětluje, jak to lze provést a jaký to může mít dopad na výkon replikace.
Pokud jste se rozhodli použít replikaci Galera napříč oběma datovými centry, platí zde také výše uvedené návrhy. Pokud jde o SSL, dříve jsme blogovali o tom, jak šifrovat provoz replikace Galera. Chcete-li získat úplnější řešení, možná budete chtít zašifrovat všechna databázová připojení z klientských aplikací a jakékoli infrastruktury pro správu/monitorování.
Nastavení nové infrastruktury
Jakmile budete mít připojení, musíte začít budovat novou infrastrukturu. K tomu pravděpodobně využijete xtrabackup nebo mariabackup. Může být lákavé zkombinovat migraci s upgradem MySQL, přece jen na novém místě nastavujete zcela nové prostředí. Nedoporučovali bychom to dělat. Migrace na novou infrastrukturu je sama o sobě dostatečně významná, takže její kombinace s další velkou změnou zvyšuje složitost a riziko. To platí i pro jiné věci – ke změnám chcete přistupovat krok za krokem. Pouze tím, že budete měnit věci jednu po druhé, můžete pochopit výsledky změn a jejich dopad na vaši pracovní zátěž – pokud jste v daný čas provedli více než jednu změnu, nemůžete si být jisti, která z nich je za danou (novou) ) chování, které jste pozorovali.
Když máte v novém datovém centru spuštěnou a spuštěnou novou instanci MySQL, musíte ji podřídit uzlu ve starém datovém centru – abyste zajistili, že data v obou datových centrech zůstanou synchronizovaná. To se vám bude hodit, když se budete připravovat na závěrečný řez. Je to také příjemný způsob, jak zajistit, aby nové prostředí zvládlo vaši zátěž při zápisu.
Dalším krokem bude vybudování kompletní stagingové infrastruktury v nové lokalitě a provedení testů a benchmarků. Toto je velmi důležitý krok, který by se neměl přeskočit – problém je v tom, že vy jako DBA musíte rozumět kapacitě své infrastruktury. Když změníte poskytovatele, změní se také věci. Nový hardware/vm jsou rychlejší nebo pomalejší. Na každou instanci je více či méně paměti. Musíte znovu pochopit, jak se vaše pracovní zatížení vejde do hardwaru, který budete používat. K tomu pravděpodobně použijete Percona Playback nebo pt-log-player k přehrání některých skutečných dotazů na stagingový systém. Budete chtít otestovat výkon a ujistit se, že je na úrovni, která je pro vás přijatelná. Chcete také provést všechny standardní akceptační testy, které spouštíte na svých nových vydáních – jen abyste se ujistili, že vše funguje a běží. Obecně by všechny aplikace měly být sestaveny tak, aby se nespoléhaly na konfiguraci hardwaru a na aktuální nastavení. Něco však mohlo uniknout a vaše aplikace může záviset na některých vylepšeních konfigurace nebo hardwarových řešeních, která v novém prostředí nemáte.
A konečně, jakmile budete se svými testy spokojeni, budete chtít vybudovat infrastrukturu připravenou k produkci. Poté, co to uděláte, možná budete chtít spustit nějaké testy pouze pro čtení pro konečné ověření. To by byl poslední krok před přerušením.
Vyříznutí
Po provedení všech těchto testů a poté, co byla infrastruktura považována za připravenou k provozu, je posledním krokem odpojení provozu od staré infrastruktury.
Globálně vzato je to složitý proces, ale když se podíváme na databázovou vrstvu, je to víceméně totéž jako standardní převzetí služeb při selhání – něco, co jste možná v minulosti provedli vícekrát. Podrobně jsme to popsali v dřívějším příspěvku, ve zkratce jsou tyto kroky:zastavit provoz, zajistit jeho zastavení, počkat, než se aplikace přesune do nového datového centra (záznamy DNS se změní nebo co ne), proveďte nějaké testy kouře, abyste zajistili vše vypadá dobře, pusťte se do živého vysílání, chvíli pozorně sledujte.
Jak vidíme, toto přerušení bude vyžadovat určité prostoje. Problém je ujistit se, že máme konzistentní stav na starém a novém webu. Pokud to chceme udělat bez prostojů, pak bychom museli nastavit replikaci master-master. Důvodem je, že když obnovujeme DNS a přesouváme relace ze starého webu na nový, oba systémy budou používány současně – dokud nebudou všechny relace přesměrovány na nový web. Mezitím se jakékoli změny na novém webu musí projevit na starém webu.
Použití Galera Cluster, jak je popsáno v tomto příspěvku na blogu, může být také způsob, jak synchronizovat data mezi těmito dvěma weby.
Jsme si vědomi, že se jedná o velmi stručný popis procesu migrace dat. Doufejme, že to bude stačit, aby vás nasměrovalo správným směrem a pomohlo vám určit, jaké další informace potřebujete hledat.