Vergelijking van hoge beschikbaarheid van database - MySQL / MariaDB-replicatie versus Oracle Data Guard

In de "State of the Open-Source DBMS Market, 2018" voorspelt Gartner dat in 2022 70 procent van de nieuwe interne applicaties op een open-source database zullen worden ontwikkeld. En 50% van de bestaande commerciële databases zal zijn geconverteerd. Dus, Oracle DBA's, bereid u voor om te beginnen met het implementeren en beheren van nieuwe open source databases - samen met uw legacy Oracle-instances. Tenzij je het al doet.

Dus hoe verhoudt MySQL of MariaDB-replicatie zich tot Oracle Data Guard? In deze blog vergelijken we de twee vanuit het oogpunt van een database-oplossing met hoge beschikbaarheid.

Waar u op moet letten

Een moderne datareplicatiearchitectuur is gebaseerd op flexibele ontwerpen die unidirectionele en bidirectionele datareplicatie mogelijk maken, evenals snelle, geautomatiseerde failover naar secundaire databases in het geval van ongeplande serviceonderbreking. Failover moet ook eenvoudig uit te voeren en betrouwbaar zijn, zodat er geen vastgelegde transacties verloren gaan. Bovendien moet omschakeling of failover idealiter transparant zijn voor applicaties.

Oplossingen voor gegevensreplicatie moeten in staat zijn om gegevens met een zeer lage latentie te kopiëren om knelpunten in de verwerking te voorkomen en realtime toegang tot gegevens te garanderen. Realtime kopieën kunnen worden geïmplementeerd op een andere database die draait op goedkope hardware.

Wanneer het wordt gebruikt voor noodherstel, moet het systeem worden gevalideerd om toegang van de toepassing tot het secundaire systeem te garanderen met minimale onderbreking van de service. De ideale oplossing zou het mogelijk moeten maken om het noodherstelproces regelmatig te testen.

Belangrijkste vergelijkingsonderwerpen

• Beschikbaarheid en consistentie van gegevens
  • Gtid, scm
  • Replicatie vermelden naar meerdere standby-, asynchrone + synchronisatiemodellen
  • Isolatie van stand-by van productiefouten (bijv. vertraagde replicatie voor mysql)
  • Voorkom gegevensverlies (synchronisatiereplicatie)
• Gebruik van standby-systemen
  • Gebruik van de stand-by
• Failover, omschakeling en automatisch herstel
  • Database-failover
  • Transparante applicatie-failover (TAF vs ProxySQL, MaxScale)
• Beveiliging
• Gebruiksgemak en beheer (geünificeerd beheer van vooraf geïntegreerde componenten)

Beschikbaarheid en consistentie van gegevens

MySQL GTID

MySQL 5.5-replicatie was gebaseerd op binaire loggebeurtenissen, waarbij een slaaf alleen de precieze gebeurtenis wist en de exacte positie die hij zojuist van de master had gelezen. Elke enkele transactie van een master kan zijn geëindigd in verschillende binaire logs van verschillende slaven, en de transactie zou normaal gesproken verschillende posities in deze logs hebben. Het was een eenvoudige oplossing met beperkingen. Bij topologiewijzigingen kan het nodig zijn dat een beheerder de replicatie op de betrokken instanties stopt. Deze wijzigingen kunnen andere problemen veroorzaken, bijvoorbeeld een slaaf kan niet door de replicatieketen worden verplaatst zonder een tijdrovende herbouw. Het repareren van een verbroken replicatielink vereist het handmatig bepalen van een nieuw binair logbestand en de positie van de laatste transactie die op de slave is uitgevoerd en van daaruit hervatten, of een totale herbouw. We hebben allemaal deze beperkingen moeten omzeilen terwijl we droomden van een wereldwijde transactie-ID.

MySQL versie 5.6 (en MariaDB versie 10.0.2) introduceerde een mechanisme om dit probleem op te lossen. GTID (Global Transaction Identifier) ​​zorgt voor een betere mapping van transacties tussen knooppunten.

Met GTID kunnen slaves een unieke transactie zien binnenkomen van verschillende masters en dit kan eenvoudig worden toegewezen aan de slave-uitvoeringslijst als het opnieuw moet worden gestart of de replicatie moet worden hervat. Het advies is dus om altijd GTID te gebruiken. Merk op dat MySQL en MariaDB verschillende GTID-implementaties hebben.

Oracle SCN

In 1992 introduceerde Oracle met de release 7.3 een oplossing om een ​​gesynchroniseerde kopie van een database stand-by te houden, bekend als Data Guard vanaf versie 9i release 2. Een Data Guard-configuratie bestaat uit twee hoofdcomponenten, een enkele primaire database en een stand-by database (tot 30). Wijzigingen in de primaire database worden doorgegeven via de secundaire database en deze wijzigingen worden toegepast op de secundaire database om deze gesynchroniseerd te houden.

Oracle Data Guard wordt in eerste instantie gemaakt op basis van een back-up van de primaire database. Data Guard synchroniseert automatisch de primaire database en alle standby-databases door de primaire database opnieuw te verzenden - de informatie die door elke Oracle-database wordt gebruikt om transacties te beschermen - en deze toe te passen op de standby-database. Oracle gebruikt een intern mechanisme genaamd SCN (System Change Number). Het systeemwijzigingsnummer (SCN) is de klok van Oracle, elke keer dat we committen, wordt de klok verhoogd. De SCN markeert een consistent tijdstip in de database, wat een controlepunt is dat de handeling is van het schrijven van vuile blokken (aangepaste blokken van de buffercache naar schijf). We kunnen het vergelijken met GTID in MySQL.

Data Guard-transportservices behandelen alle aspecten van het verzenden van opnieuw uitvoeren van een primaire naar een stand-bydatabase. Terwijl gebruikers transacties uitvoeren op de primaire, worden opnieuw records gegenereerd en weggeschreven naar een lokaal online logbestand. Data Guard-transportservices verzenden hetzelfde opnieuw uitvoeren tegelijkertijd rechtstreeks van de primaire database-logbuffer (geheugen toegewezen binnen het globale systeemgebied) naar de standby-database(s) waar het wordt weggeschreven naar een standby-logbestand voor opnieuw uitvoeren.

Er zijn een paar belangrijke verschillen tussen MySQL-replicatie en Data Guard. De directe transmissie van Data Guard vanuit het geheugen vermijdt schijf-I/O-overhead op de primaire database. Het is anders dan hoe MySQL werkt:het lezen van gegevens uit het geheugen vermindert de I/O op een primaire database.

Data Guard verzendt alleen database opnieuw. Het staat in schril contrast met opslag op afstand spiegelen, waarbij elk gewijzigd blok in elk bestand moet worden verzonden om realtime synchronisatie te behouden.

Async + Sync-modellen

Oracle Data Guard biedt drie verschillende modellen voor het opnieuw toepassen. Adaptieve modellen afhankelijk van beschikbare hardware, processen en uiteindelijk zakelijke behoeften.

• Maximale prestatie - standaard werkingsmodus, waardoor een transactie kan worden vastgelegd zodra de gegevens voor opnieuw uitvoeren die nodig zijn om die transactie te herstellen, zijn weggeschreven naar het lokale herhaallogboek op de master.
• Maximale bescherming - geen gegevensverlies en het maximale beschermingsniveau. De redo-gegevens die nodig zijn om elke bewerking te verbeteren, moeten worden geschreven naar zowel het lokale online redo-log op de master als het standby-redolog op ten minste één stand-bydatabase voordat de transactie wordt doorgevoerd (Oracle beveelt ten minste twee standbys aan). De primaire database wordt afgesloten als een fout deze verhindert om de herhalingsstroom naar ten minste één gesynchroniseerde standby-database te schrijven.
• Maximale beschikbaarheid - vergelijkbaar met maximale bescherming, maar de primaire database wordt niet afgesloten als een fout verhindert dat de opnieuw uitgevoerde stream wordt geschreven.

Als het gaat om het kiezen van uw MySQL-replicatie-installatie, hebt u de keuze tussen asynchrone replicatie of semi-synchrone replicatie.

• Asynchrone binlog toepassen is de standaardmethode voor MySQL-replicatie. De master schrijft gebeurtenissen naar zijn binaire log en slaves vragen ze op wanneer ze klaar zijn. Er is geen garantie dat een gebeurtenis ooit een slaaf zal bereiken.
• Semi-synchrone commit op primaire wordt uitgesteld totdat master een bevestiging ontvangt van de semi-synchrone slave dat gegevens zijn ontvangen en geschreven door de slave. Houd er rekening mee dat voor semi-synchrone replicatie een extra plug-in moet worden geïnstalleerd.

Gebruik van standby-systemen

MySQL staat bekend om de eenvoud en flexibiliteit van de replicatie. Standaard kunt u lezen of zelfs schrijven naar uw stand-by/slave-servers. Gelukkig brachten MySQL 5.6 en 5.7 veel belangrijke verbeteringen aan Replication, waaronder Global Transaction ID's, event checksums, multi-threaded slaves en crash-safe slaves/masters om het nog beter te maken. DBA's die gewend zijn aan MySQL-replicatie, lezen en schrijven, verwachten een vergelijkbare of zelfs eenvoudigere oplossing van zijn grotere broer, Oracle. Helaas niet standaard.

De standaard fysieke standby-implementatie voor Oracle is gesloten voor alle lees-schrijfbewerkingen. Oracle biedt in feite logische variatie, maar het heeft veel beperkingen, en het is niet ontworpen voor HA. De oplossing voor dit probleem is een extra betaalde functie genaamd Active Data Guard, die u kunt gebruiken om gegevens uit de stand-bymodus te lezen terwijl u redo-logs toepast.

Active Data Guard is een betaalde add-on-oplossing voor Oracle's gratis Data Guard-software voor noodherstel die alleen beschikbaar is voor Oracle Database Enterprise Edition (licentie met de hoogste kosten). Het biedt alleen-lezen toegang, terwijl het continu wijzigingen toepast die vanuit de primaire database zijn verzonden. Als actieve standby-database helpt het leesquery's, rapportage en incrementele back-ups van de primaire database te ontlasten. De architectuur van het product is ontworpen om stand-by-databases te isoleren van storingen die kunnen optreden in de primaire database.

Een opwindende functie van Oracle-database 12c en iets dat Oracle DBA zou missen, is de validatie van gegevenscorruptie. Er worden corruptiecontroles van Oracle Data Guard uitgevoerd om ervoor te zorgen dat de gegevens exact zijn uitgelijnd voordat de gegevens naar een stand-by-database worden gekopieerd. Dit mechanisme kan ook worden gebruikt om gegevensblokken op de primaire database rechtstreeks vanuit de standby-database te herstellen.

Failover, omschakeling en automatisch herstel

Om uw replicatie-installatie stabiel en actief te houden, is het van cruciaal belang dat het systeem bestand is tegen storingen. Storingen worden veroorzaakt door softwarefouten, configuratieproblemen of hardwareproblemen en kunnen op elk moment optreden. In het geval dat een server uitvalt, heb je een alarmmelding nodig over de verslechterde setup. Failover (promotie van een slave naar master) kan worden uitgevoerd door de beheerder, die moet beslissen welke slave moet worden gepromoveerd.

De beheerder heeft informatie nodig over de fout, de synchronisatiestatus voor het geval er gegevens verloren gaan en tot slot de stappen om de actie uit te voeren. Idealiter zou alles geautomatiseerd en zichtbaar moeten zijn vanaf één enkele console.

Er zijn twee hoofdbenaderingen voor MySQL-failover, automatisch en handmatig. Beide opties hebben fans, we beschrijven de concepten in een ander artikel.

Met de GTID wordt de handmatige failover veel eenvoudiger. Het bestaat uit stappen zoals:

• Stop de ontvangermodule (STOP SLAVE IO_THREAD)
• Schakel master (WIJZIG MASTER IN )
• Start de ontvangermodule (START SLAVE IO_THREAD)

Oracle Data Guard wordt geleverd met een speciale failover/switchover-oplossing - Data Guard Broker. De broker is een gedistribueerd beheerraamwerk dat het maken, onderhouden en bewaken van Oracle Data Guard-configuraties automatiseert en centraliseert. Met de toegang tot de DG Broker-tool kunt u configuratiewijzigingen, omschakelingen, failovers en zelfs een droge test van uw hoge-beschikbaarheidsconfiguratie uitvoeren. De twee belangrijkste acties zijn:

• De opdracht SWITCHOVER TO wordt gebruikt om de omschakeling uit te voeren. Na de succesvolle omschakeling, wisselen database-instances van plaats en gaat de replicatie verder. Het is niet mogelijk om over te schakelen wanneer stand-by niet reageert of niet actief is.
• De algemene FAILOVER TO wordt gebruikt om de failover uit te voeren. Na de failover-bewerking moet de vorige primaire server opnieuw worden gemaakt, maar de nieuwe primaire server kan de database-werkbelasting aan.

Over failover gesproken, we moeten overwegen hoe naadloos uw applicatiefailover kan zijn. Hoe efficiënt kunnen gebruikerssessies, in het geval van een geplande/ongeplande storing, naar een secundaire site worden geleid, met minimale bedrijfsonderbreking.

De standaardaanpak voor MySQL zou zijn om een ​​van de beschikbare Load Balancers te gebruiken. Beginnend met HAProxy, dat veel wordt gebruikt voor HTTP- of TCP/IP-failover, tot databasebewuste Maxscale of ProxySQL.

In Oracle wordt dit probleem aangepakt door TAF (Transparent Application Failover). Zodra omschakeling of failover plaatsvindt, wordt de toepassing automatisch doorgestuurd naar de nieuwe primaire. Met TAF kan de toepassing automatisch en transparant opnieuw verbinding maken met een nieuwe database, als de database-instantie waarmee de verbinding wordt gemaakt, faalt.

Beveiliging

Gegevensbeveiliging is tegenwoordig een hot issue voor veel organisaties. Voor degenen die standaarden zoals PCI DSS of HIPAA moeten implementeren, is databasebeveiliging een must. De cross-WAN-omgevingen kunnen leiden tot bezorgdheid over gegevensprivacy en -beveiliging, vooral omdat steeds meer bedrijven moeten voldoen aan nationale en internationale regelgeving. Binaire MySQL-logboeken die voor replicatie worden gebruikt, kunnen gemakkelijk leesbare gevoelige gegevens bevatten. Met de standaardconfiguratie is het stelen van gegevens een heel eenvoudig proces. MySQL ondersteunt SSL als een mechanisme om verkeer zowel tussen MySQL-servers (replicatie) als tussen MySQL-servers en clients te versleutelen. Een typische manier om SSL-codering te implementeren, is door zelfondertekende certificaten te gebruiken. Meestal is het niet vereist om een ​​SSL-certificaat te verkrijgen dat is uitgegeven door de certificeringsinstantie. U kunt ofwel openssl gebruiken om certificaten aan te maken, voorbeeld hieronder:

$ 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

Pas vervolgens de replicatie aan met parameters voor 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';

Voor een meer geautomatiseerde optie kunt u ClusterControl gebruiken om codering in te schakelen en SSL-sleutels te beheren.

In Oracle 12c kan Data Guard-transport opnieuw worden geïntegreerd met een reeks speciale beveiligingsfuncties, Oracle Advanced Security (OAS) genaamd. Geavanceerde beveiliging kan worden gebruikt om coderings- en authenticatieservices tussen de primaire en stand-bysystemen in te schakelen. Het inschakelen van het Advanced Encryption Standard (AES)-coderingsalgoritme vereist bijvoorbeeld slechts een paar parameterwijzigingen in het sqlnet.ora-bestand om opnieuw te doen (vergelijkbaar met MySQL binlog) versleuteld. Er is geen externe certificaatconfiguratie vereist en het vereist alleen een herstart van de standby-database. De wijziging in sqlnet.ora en portemonnee is eenvoudig als:

Maak een portemonnee-map

mkdir /u01/app/wallet

Bewerk sqlnet.ora

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

Een sleutelarchief maken

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

Winkel openen

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Maak een hoofdsleutel

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

Op stand-by

kopieer p12- en .sso-bestanden in de portemonnee-directory en update het sqlnet.ora-bestand vergelijkbaar met het primaire knooppunt.

Voor meer informatie kunt u het TDE-witboek van Oracle volgen, u kunt van het witboek leren hoe u een gegevensbestand kunt versleutelen en de portemonnee altijd open kunt maken.

Gebruiksgemak en beheer

Wanneer u de configuratie van Oracle Data Guard beheert of implementeert, kunt u ontdekken dat er veel stappen en parameters zijn waarnaar u moet zoeken. Om dat te beantwoorden heeft Oracle DG Broker opgericht.

U kunt zeker een Data Guard-configuratie maken zonder de DG Broker te implementeren, maar het kan uw leven veel comfortabeler maken. Wanneer het is geïmplementeerd, is het opdrachtregelhulpprogramma van de Broker - DGMGRL waarschijnlijk de eerste keuze voor de DBA. Voor degenen die de voorkeur geven aan GUI, heeft Cloud Control 13c een optie om toegang te krijgen tot DG Broker via de webinterface.

De taken waarmee Broker kan helpen zijn een automatische start van het beheerde herstel, één commando voor failover/switchover, monitoring van DG-replicatie, configuratieverificatie en vele andere.

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 biedt geen vergelijkbare oplossing als Oracle DG Broker. U kunt de functionaliteit echter uitbreiden met tools zoals Orchestrator, MHA en load balancers (ProxySQL, HAProxy of Maxscale). De oplossing om databases en load balancers te beheren is ClusterControl. De ClusterControl Enterprise Edition biedt u een volledige set beheer- en schaalfuncties naast de implementatie- en monitoringfuncties die worden aangeboden als onderdeel van de gratis Community Edition.