Porovnání replikačních řešení od Oracle a MySQL

Databáze mohou selhat bez varování – buď kvůli havárii způsobené softwarovou chybou, nebo základním hardwarovým komponentám. Cloud přináší do problému další rozměr, a to kvůli pomíjivé povaze výpočetních a úložných zdrojů. Abychom izolovali naši databázovou infrastrukturu od těchto selhání, zabudováváme do našich systémů redundanci. Pokud se instance stane nedostupnou, záložní systém by měl být schopen převzít pracovní zátěž a pokračovat odtamtud. Replikace je dobře známá a široce používaná metoda pro vytváření redundantních kopií hlavní databáze.

V tomto příspěvku porovnáme funkčnost replikace ve dvou nejpopulárnějších databázových systémech na planetě (podle db-engines) - Oracle a MySQL. Konkrétně se podíváme na logickou replikaci Oracle 12c a MySQL 5.7. Obě technologie nabízejí spolehlivé pohotovostní systémy pro snížení produkčního zatížení a pomoc v případě katastrofy. Podíváme se na jejich různé architektury, analyzujeme klady a zápory a projdeme si kroky, jak nastavit replikaci s Oracle a MySQL.

Architektura Oracle Data Guard – jak to funguje

Oracle Data Guard zajišťuje vysokou dostupnost, ochranu dat a obnovu vašich dat po havárii. Je to pravděpodobně první volba Oracle DBA pro replikaci dat. Technologie byla představena v roce 1990 (verze 7.0) se zásadním uplatněním archivních logů v záložních databázích. Data Guard se v průběhu let vyvíjel a nyní poskytuje komplexní sadu služeb, které vytvářejí, udržují, spravují a monitorují pohotovostní databáze.

Data Guard udržuje záložní databáze jako kopie produkční databáze. Pokud primární databáze přestane reagovat, Data Guard může přepnout jakýkoli pohotovostní režim do produkční role, čímž dojde k výpadku. Data Guard lze použít pro techniky zálohování, obnovy a clusterů, aby byla zajištěna vysoká úroveň ochrany a dostupnosti dat.

Data Guard je technologie Ship Redo / Apply Redo, "redo" jsou informace potřebné k obnovení transakcí. Produkční databáze označovaná jako primární databáze všesměrově převádí do jedné nebo více replik označovaných jako záložní databáze. Při vložení nebo aktualizaci tabulky je tato změna zachycena zapisovačem protokolu do archivního protokolu a replikována do pohotovostního systému. Pohotovostní databáze jsou v nepřetržité fázi obnovy, ověřování a opakování, aby byla zachována synchronizace s primární databází. Pohotovostní databáze se také automaticky znovu synchronizuje, pokud se dočasně odpojí od primárního zdroje kvůli výpadkům napájení, problémům se sítí atd.

Data Guard Redo Transport Services regulují přenos redo z primární databáze do záložní databáze. Proces LGWR (zapisovač protokolu) odešle data redo jednomu nebo více procesům síťového serveru (LNS1, LSN2, LSN3, ...LSNn). LNS čte z redo bufferu v SGA (Shared Global Area) a předává opakování do Oracle Net Services k přenosu do pohotovostní databáze. Můžete si vybrat atributy LGWR:synchronní (LogXptMode ='SYNC') nebo asynchronní režim (LogXptMode ='ASYNC'). S takovou architekturou je možné dodat redo data do několika záložních databází nebo je použít s Oracle RAC (Real Application Cluster). Proces vzdáleného souborového serveru (RFS) přijímá opakování z LNS a zapisuje je do běžného souboru nazývaného soubor pohotovostního protokolu redo (SRL).

Existují dva hlavní typy Oracle Data Guard. Fyzické s použitím redo a Logické rezervní databáze s použitím SQL.

Aplikace SQL vyžaduje více zpracování než použití opakování, proces nejprve načte SRL a „vytěží“ opakování jeho převedením na záznamy logických změn a poté vytvoří transakce SQL před aplikací SQL na záložní databázi. Existuje více pohyblivých částí, takže to vyžaduje více CPU, paměti a I/O, než to zopakujte.

Hlavní výhodou "aplikace SQL" je, že databáze je otevřená pro čtení i zápis, zatímco proces aplikace je aktivní.

Můžete dokonce vytvářet pohledy a místní indexy. Díky tomu je ideální pro reportovací nástroje. Pohotovostní databáze nemusí být jedna k jedné kopii vaší primární databáze, a proto nemusí být tím nejlepším kandidátem pro účely DR.

Klíčové vlastnosti tohoto řešení jsou:

• Pohotovostní databáze, která se otevře pro čtení i zápis, když je aktivní aplikace SQL
• Možný zámek úprav dat, která jsou spravována aplikací SQL
• Schopnost provádět průběžné upgrady databáze

Existují nevýhody. Oracle používá doplňkové protokolování primárního klíče nebo jedinečného omezení/indexu k logickému rozpoznání upraveného řádku v logické rezervní databázi. Je-li povoleno doplňkové protokolování primárního klíče a jedinečného omezení/indexu pro celou databázi, každý příkaz UPDATE také zapisuje hodnoty sloupců nutné do protokolu redo k jedinečné identifikaci upraveného řádku v logické rezervní databázi. Oracle Data Guard podporuje zřetězenou replikaci, která se zde nazývá „kaskáda“, ale není to typické kvůli složitosti nastavení.

Společnost Oracle doporučuje přidat primární klíč nebo nenulový jedinečný index do tabulek v primární databázi, kdykoli je to možné, aby bylo zajištěno, že SQL Apply dokáže efektivně aplikovat aktualizace dat v logickém pohotovostním režimu. To znamená, že nefunguje v žádném nastavení, možná budete muset upravit aplikaci.

Architektura Oracle Golden Gate – jak to funguje

S Data Guard se při změně bloků v databázi přidávají záznamy do redo logu. Poté na základě režimu replikace, který používáte, budou tyto záznamy protokolu buď okamžitě zkopírovány do pohotovostního režimu, nebo budou vytěženy pro příkazy SQL a použity. Golden Gate funguje jiným způsobem.

Golden Gate replikuje změny až po potvrzení transakce, takže pokud máte dlouho běžící transakci, může replikace chvíli trvat. „Proces extrahování“ Golden Gate uchovává transakční změny v paměti.

Dalším velkým rozdílem je, že Oracle Golden Gate umožňuje výměnu a manipulaci s daty na transakční úrovni mezi více heterogenními platformami. Nejste omezeni pouze na databázi Oracle. Poskytuje vám flexibilitu extrahovat a replikovat vybrané datové záznamy, transakční změny a změny DDL (jazyk pro definici dat) v různých topologiích.

Typický tok Golden Gate ukazuje nová a změněná databázová data zachycená ze zdrojové databáze. Zachycená data jsou zapsána do souboru zvaného zdrojová stopa. Záznam je poté přečten datovou pumpou, odeslán po síti a zapsán do vzdáleného souboru záznamů pomocí procesu Collector. Funkce doručení čte vzdálenou stopu a aktualizuje cílovou databázi. Každá z komponent je spravována procesem Manager.

Logická replikace MySQL – jak to funguje

Replikace v MySQL existuje již dlouhou dobu a v průběhu let se vyvíjela. Existují různé způsoby, jak povolit replikaci MySQL, včetně skupinové replikace, Galera Clusters, asynchronního „Master to Slave“. Abychom porovnali architekturu Oracle vs. MySQL, zaměříme se na replikační formáty, protože jsou základem pro všechny různé typy replikace.

Za prvé, různé formáty replikace odpovídají formátu binárního protokolování specifikovanému v konfiguračním souboru my.cnf. Bez ohledu na formát jsou protokoly vždy uloženy binárně a nelze je zobrazit běžným editorem. Existují tři typy formátů:řádkový, příkazový a smíšený. Smíšené je kombinací prvních dvou. Podíváme se na výpis a řádek.

Na základě prohlášení – v tomto případě se jedná o písemné dotazy. Ne všechny příkazy, které upravují data (jako jsou příkazy INSERT DELETE, UPDATE a REPLACE), lze replikovat pomocí replikace založené na příkazech. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() atd. nebudou replikovány.

Řádkové – v tomto případě se jedná o změny záznamů. Všechny změny lze replikovat. Toto je nejbezpečnější forma replikace. Od 5.7.7 je to výchozí možnost.

Nyní se podívejme, co se děje pod pokličkou, když je replikace povolena.

Za prvé, hlavní databáze zapisuje změny do souboru zvaného binární protokol nebo binlog. Zápis do binárního protokolu je obvykle nenáročná činnost, protože zápisy jsou ukládány do vyrovnávací paměti a jsou sekvenční. Binární soubor protokolu ukládá data, která bude replikační slave zpracovávat později, hlavní aktivita na nich nezávisí. Když se replikace spustí, mysql spustí tři vlákna. Jeden na pána, dva na otroka. Hlavní jednotka má vlákno, nazývané vlákno výpisu, které čte binární protokol hlavního serveru a doručuje jej podřízenému zařízení.

Na podřízeném zařízení se proces zvaný IO vlákno připojuje k hlavnímu serveru, čte události binárního protokolu z hlavního serveru, jakmile přicházejí, a zkopíruje je do místního souboru protokolu zvaného relay log. Druhý slave proces – SQL vlákno – čte události z předávacího protokolu uloženého lokálně na replikačním slave zařízení a poté je využívá.

MySQL podporuje řetězenou replikaci, která se velmi snadno nastavuje. Slave, které jsou zároveň mastery, musí běžet s parametry --log-bin a --log-slave-update.

Chcete-li zkontrolovat stav replikace a získat informace o vláknech, spusťte na slave:

MariaDB [(none)]> zobrazit stav otroka\G*************************** 1. řádek ** ************************* Slave_IO_State:Čeká se, až master odešle událost Master_Host:master Master_User:rpl_user Master_Port:3306 Connect_Retry:10 Master_Log_File:binlog.000005 Read_Master_Log_Pos:339 Relay_Log_File:relay-bin.000002 Relay_Log_Pos:635 Relay_Master_Log_File:binlog.000005 Slave_IO_Running:Yes Slave_SQL_Running:Yes Replicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno:0 Last_Error:Skip_Counter:0 Exec_Master_Log_Pos:339 Relay_Log_Space:938 Until_Condition:Žádný Until_Log_File :Until_Log_Pos:0 Master_SSL_Allowed:No Master_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master:0Master_SSL_Verify_Server_Cert:No Last_IO_Errno:0 Last_IO_Error:Last_SQL_Errno:0 Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id:1 Master_SSL_Crl:Master_SSL_Crlpath:Using_Gtid:Current_Pos Gtid_IO_Pos:0-1- 8 Replicate_Do_Domain_Ids:Replicate_Ignore_Domain_Ids:Parallel_Mode:konzervativní SQL_Delay:0 SQL_Remaining_Delay:NULL Slave_SQL_Running_State:Slave přečetl celý protokol přenosu; čekání, až podřízené I/O vlákno aktualizuje 1 řádek v sadě (0,00 s) 

Nastavení logické replikace Data Guard v Oracle

1. Vytvoření fyzické pohotovostní databáze

   Chcete-li vytvořit logickou rezervní databázi, musíte nejprve vytvořit fyzickou rezervní databázi a poté ji převést do logické rezervní databáze.

2. Zastavit znovu použití na databázi fyzického pohotovostního režimu

   Zastavení Znovu použít je nutné, aby se zabránilo použití změn.

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 

3. Připravte primární databázi na podporu logické pohotovostní databáze

   Změňte atribut VALID_FOR v původním LOG_ARCHIVE_DEST_1 a přidejte LOG_ARCHIVE_DEST_3 pro logickou databázi.

   LOG_ARCHIVE_DEST_1='LOCATION=/oblouk1/několik ninek/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines'LOG_ARCHIVE_DEST_3='LOCATION=/oblouk2/několik ninek/ VALID_3DBNESLOGEN=UNI_STAT_STATRO, VALEBYDFOR=vždy DB_UNIQUE_NAME=POVOLIT 

   Vytvoření slovníku v datech Redo

   SQL> EXECUTE DBMS_LOGSTDBY.BUILD; 

4. Převést na logickou pohotovostní databázi

   Chcete-li pokračovat v používání dat opakování na fyzickou pohotovostní databázi, dokud nebude připravena k převodu na logickou pohotovostní databázi, zadejte následující příkaz SQL:

   SQL> ZMĚŇTE OBNOVENÍ DATABÁZE DO LOGICKÉHO STANDBY název_db; 

5. Úprava inicializačních parametrů pro databázi logického pohotovostního režimu

   log_archive_dest_1 ='location =/arch1/několiknines_remote/valid_for =(online_logfiles, all_roles) db_unique_name =několikNines_remote'log_archive_dest_2 =' location =locas =async valid_for =(online_logfiles) /arch2/severalnines_remote/VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_3=DEST_STATESTAT>

6. Otevřete databázi logického pohotovostního režimu

   SQL> ALTER DATABASE OPEN RESETLOGS; 

   Ověřte, že databáze logického pohotovostního režimu funguje správně

   zobrazení v$data_guard_stats

   SQL> FORMÁT NÁZEV COL A20SQL> FORMÁT HODNOTY COL A12SQL> FORMÁT JEDNOTKY COL A30SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; JMÉNO HODNOTA JEDNOTKA-------------------- ------------ ---------------- ---------------použít čas dokončení +00 00:00:00 den(2) až sekunda(1) intervalpoužít zpoždění +00 00:00:00 den(2) až sekunda( 0) intervaltransport lag +00 00:00:00 den(2) až sekunda(0) interval 

   v$logstdby_processview

   SQL> FORMÁT SLOUPCE SERIAL# 9999SQL> FORMÁT SIDLA SLOUPCE 9999SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL # SPID TYPE HIGH_SCN ----- ------- ----------- --------------- ----- -----48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 Vybráno 9 řádků.