Jämförelse av databas med hög tillgänglighet - MySQL / MariaDB-replikering vs Oracle Data Guard

I "State of the Open-Source DBMS Market, 2018", förutspår Gartner att år 2022 kommer 70 procent av nya interna applikationer att utvecklas på en öppen källkodsdatabas. Och 50 % av befintliga kommersiella databaser kommer att ha konverterats. Så, Oracle DBA:er, gör dig redo att börja distribuera och hantera nya databaser med öppen källkod – tillsammans med dina äldre Oracle-instanser. Såvida du inte redan gör det.

Så hur fungerar MySQL- eller MariaDB-replikering mot Oracle Data Guard? I den här bloggen kommer vi att jämföra de två utifrån en databaslösning med hög tillgänglighet.

Vad du ska leta efter

En modern datareplikeringsarkitektur bygger på flexibla konstruktioner som möjliggör enkelriktad och dubbelriktad datareplikering, såväl som snabb, automatiserad failover till sekundära databaser i händelse av oplanerat tjänstavbrott. Failover ska också vara lätt att utföra och pålitligt så att inga engagerade transaktioner skulle gå förlorade. Dessutom bör omkoppling eller failover helst vara transparent för applikationer.

Datareplikeringslösningar måste kunna kopiera data med mycket låg latens för att undvika bearbetning av flaskhalsar och garantera tillgång till data i realtid. Realtidskopior kan distribueras på en annan databas som körs på billig hårdvara.

När det används för katastrofåterställning måste systemet valideras för att säkerställa applikationsåtkomst till det sekundära systemet med minimalt avbrott i tjänsten. Den idealiska lösningen bör tillåta regelbunden testning av katastrofåterställningsprocessen.

Huvudämnen för jämförelse

• Datatillgänglighet och konsistens
  • Gtid, scm
  • Nämn replikering till flera standby-, asynkron- och synkroniseringsmodeller
  • Isolering av standby från produktionsfel (t.ex. fördröjd replikering för mysql)
  • Undvik förlust av data (synkroniseringsreplikering)
• Användning av standby-system
  • Användning av vänteläget
• Failover, Switchover och automatisk återställning
  • Databasfel
  • Transparent programfelövergång (TAF vs ProxySQL, MaxScale)
• Säkerhet
• Lätt att använda och hantera (enhetlig hantering av förintegrerade komponenter)

Datatillgänglighet och konsistens

MySQL GTID

MySQL 5.5-replikering baserades på binära logghändelser, där allt en slav visste var den exakta händelsen och den exakta positionen den just läste från mastern. Varje enskild transaktion från en master kan ha slutat i olika binära loggar från olika slavar, och transaktionen skulle vanligtvis ha olika positioner i dessa loggar. Det var en enkel lösning som kom med begränsningar, topologiändringar kunde kräva att en administratör stoppar replikering på de inblandade instanserna. Dessa ändringar kan orsaka vissa andra problem, t.ex. en slav kunde inte flyttas ner i replikeringskedjan utan en tidskrävande ombyggnad. Att fixa en trasig replikeringslänk skulle kräva manuell bestämning av en ny binär loggfil och position för den senaste transaktionen som utfördes på slaven och återuppta därifrån, eller en total ombyggnad. Vi har alla varit tvungna att kringgå dessa begränsningar medan vi drömt om en global transaktionsidentifierare.

MySQL version 5.6 (och MariaDB version 10.0.2) introducerade en mekanism för att lösa detta problem. GTID (Global Transaction Identifier) ​​ger bättre mappning av transaktioner över noder.

Med GTID kan slavar se en unik transaktion som kommer in från flera masters och denna kan enkelt mappas till slavexekveringslistan om den behöver starta om eller återuppta replikering. Så, rådet är att alltid använda GTID. Observera att MySQL och MariaDB har olika GTID-implementationer.

Oracle SCN

1992 med release 7.3 introducerade Oracle en lösning för att hålla en synkroniserad kopia av en databas som standby, känd som Data Guard från version 9i release 2. En Data Guard-konfiguration består av två huvudkomponenter, en enda primär databas och en standby-databas (upp till 30). Ändringar på den primära databasen skickas genom standbydatabasen, och dessa ändringar tillämpas på standbydatabasen för att hålla den synkroniserad.

Oracle Data Guard skapas initialt från en säkerhetskopia av den primära databasen. Data Guard synkroniserar automatiskt den primära databasen och alla standby-databaser genom att överföra den primära databasen redo - informationen som används av varje Oracle Database för att skydda transaktioner - och applicera den på standby-databasen. Oracle använder en intern mekanism som kallas SCN (System Change Number). Systemändringsnumret (SCN) är Oracles klocka, varje gång vi förbinder oss, ökar klockan. SCN markerar en konsekvent tidpunkt i databasen som är en kontrollpunkt som är handlingen att skriva smutsiga block (modifierade block från buffertcachen till disken). Vi kan jämföra det med GTID i MySQL.

Data Guard transporttjänster hanterar alla aspekter av sändning av redo från en primär till en standby-databas. När användare utför transaktioner på den primära, genereras redo-poster och skrivs till en lokal onlineloggfil. Data Guards transporttjänster sänder samtidigt samma redo direkt från den primära databasloggbufferten (minne allokerat inom systemets globala område) till standbydatabasen(-erna) där den skrivs till en standby redo-loggfil.

Det finns några huvudskillnader mellan MySQL-replikering och Data Guard. Data Guards direkta överföring från minnet undviker disk I/O-overhead på den primära databasen. Det skiljer sig från hur MySQL fungerar - att läsa data från minnet minskar I/O på en primär databas.

Data Guard sänder endast databas redo. Det står i skarp kontrast till lagringsfjärrspegling som måste överföra varje ändrat block i varje fil för att upprätthålla realtidssynkronisering.

Async + Sync-modeller

Oracle Data Guard erbjuder tre olika modeller för att göra om ansökan. Adaptiva modeller beroende på tillgänglig hårdvara, processer och i slutändan affärsbehov.

• Maximal prestanda - standardläge, vilket gör att en transaktion kan utföras så snart den redogöringsdata som behövs för att återställa transaktionen skrivs till den lokala redo-loggen på mastern.
• Maximalt skydd – ingen dataförlust och maximal skyddsnivå. Den redogöringsdata som behövs för att förbättra varje operation måste skrivas till både den lokala online-redologgen på mastern och standby-redologgen på minst en standby-databas innan transaktionen genomförs (Oracle rekommenderar minst två standby-lägen). Den primära databasen stängs av om ett fel blockerar den från att skriva sin redo-ström till minst en synkroniserad standby-databas.
• Maximal tillgänglighet - liknar maximalt skydd men den primära databasen kommer inte att stängas av om ett fel hindrar den från att skriva om strömmen.

När det kommer till att välja din MySQL-replikeringsinställning har du valet mellan asynkron replikering eller semisynkron replikering.

• Asynchronous binlog application är standardmetoden för MySQL-replikering. Mastern skriver händelser till sin binära logg och slavar begär dem när de är redo. Det finns ingen garanti för att någon händelse någonsin kommer att nå någon slav.
• Halvsynkron commit på primär är fördröjd tills master får en bekräftelse från den semisynkrona slaven att data tas emot och skrivs av slaven. Observera att semi-synkron replikering kräver en extra plugin för att installeras.

Användning av standbysystem

MySQL är välkänt för sin replikeringsenkelhet och flexibilitet. Som standard kan du läsa eller till och med skriva till dina standby-/slavservrar. Lyckligtvis medförde MySQL 5.6 och 5.7 många betydande förbättringar av replikering, inklusive globala transaktions-ID:n, händelsekontrollsummor, flertrådade slavar och kraschsäkra slavar/masters för att göra det ännu bättre. DBA:er som är vana vid läsning och skrivning av MySQL-replikering skulle förvänta sig en liknande eller till och med enklare lösning från sin storebror Oracle. Tyvärr inte som standard.

Standardimplementeringen för fysisk standby för Oracle är stängd för alla läs- och skrivoperationer. Faktum är att Oracle erbjuder logisk variation men det har många begränsningar, och det är inte designat för HA. Lösningen på det här problemet är en extra betald funktion som kallas Active Data Guard, som du kan använda för att läsa data från vänteläget medan du använder redo-loggar.

Active Data Guard är en betald tilläggslösning till Oracles kostnadsfria Data Guard-programvara för katastrofåterställning som endast är tillgänglig för Oracle Database Enterprise Edition (högsta kostnadslicens). Den ger skrivskyddad åtkomst, samtidigt som ändringar som skickas från den primära databasen tillämpas kontinuerligt. Som en aktiv standby-databas hjälper den till att ladda läsfrågor, rapportering och inkrementella säkerhetskopior från den primära databasen. Produktens arkitektur är utformad för att tillåta standby-databaser att isoleras från fel som kan uppstå i den primära databasen.

En spännande funktion i Oracle-databasen 12c och något som Oracle DBA skulle sakna är valideringen av datakorruption. Korruptionskontroller av Oracle Data Guard utförs för att säkerställa att data är exakt i linje innan data kopieras till en standby-databas. Denna mekanism kan också användas för att återställa datablock på den primära direkt från standby-databasen.

Failover, Switchover och Automatisk Återställning

För att hålla replikeringsinställningarna stabila och igång, är det avgörande att systemet är motståndskraftigt mot fel. Fel orsakas av antingen programvarubuggar, konfigurationsproblem eller hårdvaruproblem och kan inträffa när som helst. Om en server går ner behöver du ett larmmeddelande om den försämrade inställningen. Failover (befordran av en slav till master) kan utföras av administratören, som måste bestämma vilken slav som ska befordras.

Administratören behöver information om felet, synkroniseringsstatusen om någon data skulle gå förlorad, och slutligen, steg för att utföra åtgärden. Helst bör alla vara automatiserade och synliga från en enda konsol.

Det finns två huvudsakliga metoder för MySQL failover, automatisk och manuell. Båda alternativen har sina fans, vi beskriver begreppen i en annan artikel.

Med GTID blir den manuella failoveren mycket enklare. Den består av steg som:

• Stoppa mottagarmodulen (STOPPA SLAVE IO_THREAD)
• Byt master (ÄNDRA MASTER TILL )
• Starta mottagarmodulen (START SLAVE IO_THREAD)

Oracle Data Guard kommer med en dedikerad failover/switchover-lösning - Data Guard Broker. Mäklaren är ett distribuerat hanteringsramverk som automatiserar och centraliserar skapandet, underhållet och övervakningen av Oracle Data Guard-konfigurationer. Med tillgången till DG-mäklarverktyget kan du utföra konfigurationsändringar, omställningar, failovers och till och med torrtest av din högtillgänglighetsinställning. De två huvudsakliga åtgärderna är:

• Kommandot SWITCHOVER TO används för att utföra omkopplingsoperationen. Efter den lyckade övergången byter databasinstanser plats och replikeringen fortsätter. Det är inte möjligt att växla när standbyläget inte svarar eller det är nere.
• Den gemensamma FAILOVER TO används för att utföra failover. Efter failover-operationen kräver den tidigare primära servern återskapande men den nya primära kan ta databasbelastningen.

På tal om failover måste vi överväga hur sömlös din applikationsfailover kan vara. I händelse av ett planerat/oplanerat avbrott, hur effektivt kan användarsessioner dirigeras till en sekundär webbplats, med minimala affärsavbrott.

Standardmetoden för MySQL skulle vara att använda en av de tillgängliga lastbalanserarna. Från HAProxy som används allmänt för HTTP eller TCP/IP failover till databasmedveten Maxscale eller ProxySQL.

I Oracle åtgärdas detta problem av TAF (Transparent Application Failover). När omställningen eller failover sker, dirigeras applikationen automatiskt till den nya primära. TAF gör det möjligt för applikationen att automatiskt och transparent återansluta till en ny databas, om databasinstansen som anslutningen görs till misslyckas.

Säkerhet

Datasäkerhet är en het fråga för många organisationer nuförtiden. För dem som behöver implementera standarder som PCI DSS eller HIPAA är databassäkerhet ett måste. Cross WAN-miljöerna kan leda till oro för datasekretess och säkerhet, särskilt eftersom fler företag måste följa nationella och internationella regler. MySQL binära loggar som används för replikering kan innehålla lättlästa känsliga data. Med standardkonfigurationen är det en mycket enkel process att stjäla data. MySQL stöder SSL som en mekanism för att kryptera trafik både mellan MySQL-servrar (replikering) och mellan MySQL-servrar och klienter. Ett typiskt sätt att implementera SSL-kryptering är att använda självsignerade certifikat. För det mesta är det inte nödvändigt att skaffa ett SSL-certifikat utfärdat av certifikatutfärdaren. Du kan antingen använda openssl för att skapa certifikat, exemplet nedan:

$ 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.pem

Ändra sedan replikering med parametrar för 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';

För ett mer automatiserat alternativ kan du använda ClusterControl för att aktivera kryptering och hantera SSL-nycklar.

I Oracle 12c kan Data Guard redo transport integreras med en uppsättning dedikerade säkerhetsfunktioner som kallas Oracle Advanced Security (OAS). Avancerad säkerhet kan användas för att aktivera kryptering och autentiseringstjänster mellan det primära och standby-systemet. Till exempel, aktivering av Advanced Encryption Standard (AES) krypteringsalgoritm kräver bara ett fåtal parameterändringar i filen sqlnet.ora för att göra redo (liknande MySQL binlog) krypterad. Ingen extern certifikatinställning krävs och den kräver bara en omstart av standbydatabasen. Ändringen i sqlnet.ora och plånbok är enkla som:

Skapa en plånbokskatalog

mkdir /u01/app/wallet

Redigera sqlnet.ora

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=file)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/wallet)))

Skapa ett nyckellager

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;

Öppna butik

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Skapa en huvudnyckel

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

I vänteläge

kopiera p12- och .sso-filer i plånbokskatalogen och för att uppdatera filen sqlnet.ora som liknar den primära noden.

För mer information, följ Oracles TDE-vitbok, du kan lära dig från whitepaperet hur du krypterar datafiler och gör plånboken alltid öppen.

Lätt att använda och hantera

När du hanterar eller distribuerar Oracle Data Guard-konfiguration kan du upptäcka att det finns många steg och parametrar att leta efter. För att svara på det skapade Oracle DG Broker.

Du kan säkert skapa en Data Guard-konfiguration utan att implementera DG Broker men det kan göra ditt liv mycket bekvämare. När det är implementerat är mäklarens kommandoradsverktyg - DGMGRL förmodligen det primära valet för DBA. För dem som föredrar GUI har Cloud Control 13c en möjlighet att komma åt DG Broker via webbgränssnittet.

De uppgifter som Broker kan hjälpa till med är en automatisk start av den hanterade återställningen, ett kommando för failover/switchover, övervakning av DG-replikering, konfigurationsverifiering och många andra.

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 ago

MySQL erbjuder inte en liknande lösning som Oracle DG Broker. Men du kan utöka dess funktionalitet genom att använda verktyg som Orchestrator, MHA och lastbalanserare (ProxySQL, HAProxy eller Maxscale). Lösningen för att hantera databaser och lastbalanserare är ClusterControl. ClusterControl Enterprise Edition ger dig en komplett uppsättning hanterings- och skalningsfunktioner utöver de distributions- och övervakningsfunktioner som erbjuds som en del av den kostnadsfria Community Edition.