Ve „Stav trhu Open-Source DBMS, 2018“ Gartner předpovídá, že do roku 2022 bude 70 procent nových interních aplikací vyvíjeno na open-source databázi. A 50 % stávajících komerčních databází bude převedeno. Takže, správci Oracle DBA, připravte se na zavádění a správu nových databází s otevřeným zdrojovým kódem – spolu s vašimi staršími instancemi Oracle. Pokud to již neděláte.
Jak tedy obstojí replikace MySQL nebo MariaDB oproti Oracle Data Guard? V tomto blogu je porovnáme z hlediska vysoce dostupného databázového řešení.
Co hledat
Moderní architektura replikace dat je postavena na flexibilních návrzích, které umožňují jednosměrnou a obousměrnou replikaci dat a také rychlé, automatizované převzetí služeb při selhání do sekundárních databází v případě neplánovaného přerušení služby. Failover by měl být také snadno proveditelný a spolehlivý, aby nedošlo ke ztrátě žádné potvrzené transakce. Kromě toho by přepnutí nebo převzetí služeb při selhání mělo být pro aplikace v ideálním případě transparentní.
Řešení replikace dat musí být schopna kopírovat data s velmi nízkou latencí, aby se předešlo problémům při zpracování a zaručil přístup k datům v reálném čase. Kopie v reálném čase lze nasadit na jinou databázi běžící na levném hardwaru.
Při použití pro zotavení po havárii musí být systém ověřen, aby byl zajištěn přístup aplikace k sekundárnímu systému s minimálním přerušením služby. Ideální řešení by mělo umožňovat pravidelné testování procesu obnovy po havárii.
Hlavní témata srovnání
- Dostupnost a konzistence dat
- Gtid, scm
- Zmínit replikaci do více pohotovostních, asynchronních + synchronizačních modelů
- Izolace pohotovostního režimu od produkčních chyb (např. zpožděná replikace pro mysql)
- Zabraňte ztrátě dat (synchronizační replikace)
- Využití pohotovostních systémů
- Použití pohotovostního režimu
- Přepnutí při selhání, přepnutí a automatické obnovení
- Přepnutí při selhání databáze
- Transparentní převzetí služeb při selhání aplikace (TAF vs ProxySQL, MaxScale)
- Zabezpečení
- Snadné použití a správa (jednotná správa předem integrovaných komponent)
Dostupnost a konzistence dat
MySQL GTID
Replikace MySQL 5.5 byla založena na binárních událostech protokolu, kde jediné, co slave věděl, byla přesná událost a přesná pozice, kterou právě načetl z mastera. Každá jednotlivá transakce z hlavního serveru mohla skončit v různých binárních protokolech od různých podřízených zařízení a transakce by v těchto protokolech měla obvykle různé pozice. Bylo to jednoduché řešení s omezeními, změny topologie mohly vyžadovat, aby správce zastavil replikaci na příslušných instancích. Tyto změny mohou způsobit některé další problémy, například slave nelze přesunout dolů v řetězci replikace bez časově náročné přestavby. Oprava nefunkčního odkazu replikace by vyžadovala ruční určení nového binárního souboru protokolu a pozice poslední transakce provedené na podřízeném zařízení a obnovení odtamtud, nebo celkovou obnovu. Všichni jsme museli obejít tato omezení, když jsme snili o globálním identifikátoru transakce.
MySQL verze 5.6 (a MariaDB verze 10.0.2) zavedly mechanismus k vyřešení tohoto problému. GTID (Global Transaction Identifier) poskytuje lepší mapování transakcí napříč uzly.
S GTID mohou podřízení vidět jedinečnou transakci přicházející od několika masterů a to lze snadno namapovat do seznamu provedení slave, pokud potřebuje restartovat nebo obnovit replikaci. Doporučuje se tedy vždy používat GTID. Všimněte si, že MySQL a MariaDB mají různé implementace GTID.
Oracle SCN
V roce 1992 s vydáním 7.3 Oracle představil řešení pro uchování synchronizované kopie databáze jako pohotovostního režimu, známého jako Data Guard od verze 9i vydání 2. Konfigurace Data Guard se skládá ze dvou hlavních komponent, jedné primární databáze a záložní databáze. (do 30). Změny v primární databázi jsou předávány přes záložní databázi a tyto změny jsou aplikovány na záložní databázi, aby byla synchronizována.
Oracle Data Guard je zpočátku vytvořen ze zálohy primární databáze. Data Guard automaticky synchronizuje primární databázi a všechny pohotovostní databáze tím, že přenese primární databázi znovu – informace používané každou databází Oracle k ochraně transakcí – a použije je v pohotovostní databázi. Oracle používá interní mechanismus zvaný SCN (System Change Number). Číslo systémové změny (SCN) jsou hodiny společnosti Oracle, pokaždé, když provedeme potvrzení, hodiny se zvýší. SCN označuje konzistentní bod v čase v databázi, což je kontrolní bod, který je aktem zápisu nečistých bloků (upravených bloků z mezipaměti na disk). Můžeme to přirovnat ke GTID v MySQL.
Transportní služby Data Guard zvládají všechny aspekty přenosu redo z primární do záložní databáze. Když uživatelé zadávají transakce na primárním serveru, jsou generovány záznamy opakování a zapisovány do místního souboru online protokolu. Transportní služby Data Guard současně přenášejí stejné opakování přímo z vyrovnávací paměti protokolu primární databáze (paměť alokovaná v rámci globální oblasti systému) do záložní databáze (databází), kde se zapisuje do souboru pohotovostního protokolu opakování.
Mezi replikací MySQL a Data Guard je několik hlavních rozdílů. Přímý přenos Data Guard z paměti zabraňuje režii diskových I/O na primární databázi. Je to odlišné od toho, jak funguje MySQL – čtení dat z paměti snižuje I/O na primární databázi.
Data Guard přenáší pouze opakování databáze. Je to v ostrém kontrastu se vzdáleným zrcadlením úložiště, které musí přenášet každý změněný blok v každém souboru, aby byla zachována synchronizace v reálném čase.
Asynchronní + synchronizované modely
Oracle Data Guard nabízí tři různé modely pro opakované použití. Adaptivní modely závislé na dostupném hardwaru, procesech a v konečném důsledku na obchodních potřebách.
- Maximální výkon – výchozí režim provozu, který umožňuje potvrzení transakce, jakmile jsou data znovu potřebná k obnovení transakce zapsána do místního protokolu opakování na hlavním serveru.
- Maximální ochrana – žádná ztráta dat a maximální úroveň ochrany. Data opakování potřebná ke zlepšení každé operace musí být zapsána jak do místního online protokolu opakování na hlavním serveru, tak do pohotovostního protokolu opakování alespoň jedné pohotovostní databáze, než se transakce potvrdí (Oracle doporučuje alespoň dva pohotovostní režimy). Primární databáze se vypne, pokud ji chyba zablokuje zápis svého redo streamu do alespoň jedné synchronizované záložní databáze.
- Maximální dostupnost – podobná jako u Maximální ochrany, ale primární databáze se neukončí, pokud chyba zabrání v zápisu datového proudu znovu.
Pokud jde o výběr nastavení replikace MySQL, máte na výběr mezi asynchronní replikací nebo semisynchronní replikací.
- Asynchronní použití binlogu je výchozí metodou replikace MySQL. Master zapisuje události do svého binárního protokolu a podřízené jednotky si je vyžádají, když jsou připraveny. Neexistuje žádná záruka, že se nějaká událost někdy dostane k nějakému otrokovi.
- Semisynchronní potvrzování na primárním je zpožděno, dokud master neobdrží potvrzení od semisynchronního slave zařízení, že data jsou přijata a zapsána slave. Upozorňujeme, že semisynchronní replikace vyžaduje instalaci dalšího pluginu.
Využití pohotovostních systémů
MySQL je dobře známé pro svou jednoduchost a flexibilitu replikace. Ve výchozím nastavení můžete číst nebo dokonce zapisovat na své pohotovostní/podřízené servery. Naštěstí MySQL 5.6 a 5.7 přinesly do replikace mnoho významných vylepšení, včetně globálních ID transakcí, kontrolních součtů událostí, vícevláknových slave a bezpečných slave/masterů, aby byla ještě lepší. DBA zvyklí na čtení a zápis replikace MySQL by očekávali podobné nebo dokonce jednodušší řešení od svého většího bratra, společnosti Oracle. Bohužel ne ve výchozím nastavení.
Standardní implementace fyzického pohotovostního režimu pro Oracle je uzavřena pro jakékoli operace čtení a zápisu. Ve skutečnosti Oracle nabízí logické variace, ale má mnoho omezení a není určen pro HA. Řešením tohoto problému je další placená funkce nazvaná Active Data Guard, kterou můžete použít ke čtení dat z pohotovostního režimu, zatímco používáte opakování protokolů.
Active Data Guard je placené doplňkové řešení k bezplatnému softwaru Oracle pro obnovu po havárii Data Guard, který je k dispozici pouze pro Oracle Database Enterprise Edition (nejnákladnější licence). Poskytuje přístup pouze pro čtení, přičemž neustále aplikuje změny odeslané z primární databáze. Jako aktivní pohotovostní databáze pomáhá snižovat zatížení čtených dotazů, sestav a přírůstkových záloh z primární databáze. Architektura produktu je navržena tak, aby umožňovala izolovat záložní databáze od selhání, ke kterým může dojít v primární databázi.
Vzrušující funkce databáze Oracle 12c a něco, co by Oracle DBA postrádalo, je ověřování poškození dat. Před zkopírováním dat do záložní databáze se provádějí kontroly poškození Oracle Data Guard, aby bylo zajištěno, že jsou data v přesném zarovnání. Tento mechanismus lze také použít k obnovení datových bloků na primárním zařízení přímo z pohotovostní databáze.
Přepnutí při selhání, přepnutí a automatické obnovení
Aby vaše nastavení replikace zůstalo stabilní a spuštěné, je zásadní, aby byl systém odolný vůči selháním. Selhání jsou způsobena buď chybami softwaru, problémy s konfigurací nebo problémy s hardwarem a mohou nastat kdykoli. V případě, že dojde k výpadku serveru, potřebujete upozornění na alarm o zhoršeném nastavení. Failover (povýšení otroka na master) může provést administrátor, který musí rozhodnout, kterého otroka povýší.
Administrátor potřebuje informace o selhání, stavu synchronizace v případě ztráty dat a nakonec kroky k provedení akce. V ideálním případě by vše mělo být automatizované a viditelné z jediné konzole.
Existují dva hlavní přístupy k převzetí služeb při selhání MySQL, automatický a manuální. Obě možnosti mají své fanoušky, pojmy popisujeme v jiném článku.
S GTID je manuální převzetí služeb při selhání mnohem jednodušší. Skládá se z kroků jako:
- Zastavte modul přijímače (STOP SLAVE IO_THREAD)
- Přepnout master (ZMĚNIT MASTER NA
) - Spusťte modul přijímače (START SLAVE IO_THREAD)
Oracle Data Guard přichází s vyhrazeným řešením pro převzetí služeb při selhání/přepnutí – Data Guard Broker. Broker je distribuovaný rámec pro správu, který automatizuje a centralizuje vytváření, údržbu a monitorování konfigurací Oracle Data Guard. S přístupem k nástroji DG broker můžete provádět změny konfigurace, přepnutí, přepnutí při selhání a dokonce i suchý test vašeho nastavení vysoké dostupnosti. Dvě hlavní akce jsou:
- Příkaz SWITCHOVER TO
se používá k provedení operace přepnutí. Po úspěšné operaci přechodu se instance databáze vymění a replikace pokračuje. Není možné přepnout, když pohotovostní režim nereaguje nebo je vypnutý. - K provedení převzetí služeb při selhání se používá běžný FAILOVER TO
. Po operaci převzetí služeb při selhání vyžaduje předchozí primární server obnovení, ale nový primární server může převzít pracovní zátěž databáze.
Když už mluvíme o převzetí služeb při selhání, musíme zvážit, jak bezproblémové může být převzetí služeb při selhání vaší aplikace. V případě plánovaného/neplánovaného výpadku, jak efektivně mohou být uživatelské relace směrovány na sekundární web s minimálním přerušením podnikání.
Standardním přístupem pro MySQL by bylo použití jednoho z dostupných Load Balancerů. Počínaje HAProxy, které se široce používá pro převzetí služeb při selhání HTTP nebo TCP/IP, až po Maxscale nebo ProxySQL s podporou databáze.
V Oracle tento problém řeší TAF (Transparent Application Failover). Jakmile dojde k přepnutí nebo převzetí služeb při selhání, aplikace je automaticky přesměrována na nový primární server. TAF umožňuje aplikaci automaticky a transparentně se znovu připojit k nové databázi, pokud selže instance databáze, ke které je připojení vytvořeno.
Zabezpečení
Bezpečnost dat je v dnešní době pro mnoho organizací žhavým problémem. Pro ty, kteří potřebují implementovat standardy jako PCI DSS nebo HIPAA, je zabezpečení databáze nutností. Prostředí napříč WAN může vést k obavám o soukromí a zabezpečení dat, zejména proto, že stále více podniků musí dodržovat národní a mezinárodní předpisy. Binární protokoly MySQL používané pro replikaci mohou obsahovat snadno čitelná citlivá data. Se standardní konfigurací je krádež dat velmi snadný proces. MySQL podporuje SSL jako mechanismus pro šifrování provozu mezi servery MySQL (replikace) a mezi servery MySQL a klienty. Typickým způsobem implementace šifrování SSL je použití certifikátů s vlastním podpisem. Ve většině případů není vyžadováno získání certifikátu SSL vydaného certifikační autoritou. K vytvoření certifikátů můžete buď použít openssl, příklad níže:
$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pemPoté upravte replikaci pomocí parametrů pro SSL.
….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';Pro více automatizované možnosti můžete použít ClusterControl k povolení šifrování a správě klíčů SSL.
V Oracle 12c lze přenos Data Guard redo integrovat se sadou vyhrazených bezpečnostních funkcí nazývaných Oracle Advanced Security (OAS). Pokročilé zabezpečení lze použít k povolení služeb šifrování a ověřování mezi primárním a pohotovostním systémem. Například aktivace šifrovacího algoritmu Advanced Encryption Standard (AES) vyžaduje pouze několik změn parametrů v souboru sqlnet.ora, aby bylo opakování (podobně jako binlog MySQL) zašifrováno. Není vyžadováno žádné nastavení externího certifikátu a vyžaduje pouze restart záložní databáze. Modifikace v sqlnet.ora a wallet jsou jednoduché jako:
Vytvořte adresář peněženky
mkdir /u01/app/walletUpravit sqlnet.ora
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/u01/app/wallet)))Vytvořte úložiště klíčů
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;Otevřít obchod
ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;Vytvořte hlavní klíč
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;V pohotovostním režimu
zkopírujte soubory p12 a .sso do adresáře peněženky a aktualizujte soubor sqlnet.ora podobně jako primární uzel.
Pro více informací prosím sledujte TDE white paper společnosti Oracle, z whitepaperu se můžete dozvědět, jak šifrovat datový soubor a zajistit, aby byla peněženka vždy otevřená.
Snadné použití a správa
Při správě nebo nasazení konfigurace Oracle Data Guard možná zjistíte, že existuje mnoho kroků a parametrů, které je třeba hledat. Aby na to odpověděl Oracle, vytvořil DG Broker.
Určitě můžete vytvořit konfiguraci Data Guard bez implementace DG Broker, ale může vám to udělat mnohem pohodlnější život. Když je implementován, nástroj příkazového řádku Brokera - DGMGRL je pravděpodobně primární volbou pro DBA. Pro ty, kteří preferují GUI, má Cloud Control 13c možnost přístupu k DG Broker přes webové rozhraní.
Úlohy, se kterými může Broker pomoci, jsou automatické spuštění řízené obnovy, jeden příkaz pro převzetí služeb při selhání/přepnutí, sledování replikace DG, ověření konfigurace a mnoho dalších.
DGMGRL> show configuration
Configuration - orcl_s9s_config
Protection Mode: MaxPerformance
Members:
s9sp - Primary database
s9ss - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 12 seconds agoMySQL nenabízí podobné řešení jako Oracle DG Broker. Jeho funkčnost však můžete rozšířit pomocí nástrojů jako Orchestrator, MHA a load balancers (ProxySQL, HAProxy nebo Maxscale). Řešením pro správu databází a load balancerů je ClusterControl. ClusterControl Enterprise Edition vám poskytuje úplnou sadu funkcí pro správu a škálování kromě funkcí nasazení a monitorování nabízených jako součást bezplatné edice Community.