Sammenligning af høj tilgængelighed af databaser - MySQL / MariaDB-replikering vs Oracle Data Guard

I "State of the Open-Source DBMS Market, 2018", forudsiger Gartner, at i 2022 vil 70 procent af de nye interne applikationer blive udviklet på en open source-database. Og 50 % af eksisterende kommercielle databaser vil være konverteret. Så, Oracle DBA'er, gør dig klar til at begynde at implementere og administrere nye open source-databaser - sammen med dine ældre Oracle-instanser. Medmindre du allerede gør det.

Så hvordan fungerer MySQL- eller MariaDB-replikering i forhold til Oracle Data Guard? I denne blog vil vi sammenligne de to ud fra synspunktet om en databaseløsning med høj tilgængelighed.

Hvad skal du kigge efter

En moderne datareplikeringsarkitektur er bygget på fleksible designs, der muliggør ensrettet og tovejs datareplikering samt hurtig, automatiseret failover til sekundære databaser i tilfælde af uplanlagt tjenestebrud. Failover skal også være let at udføre og pålideligt, så ingen forpligtede transaktioner går tabt. Desuden bør switchover eller failover ideelt set være transparent for applikationer.

Datareplikeringsløsninger skal være i stand til at kopiere data med meget lav latenstid for at undgå behandling af flaskehalse og garantere realtidsadgang til data. Realtidskopier kunne implementeres på en anden database, der kører på billig hardware.

Når det bruges til katastrofegendannelse, skal systemet valideres for at sikre applikationsadgang til det sekundære system med minimal serviceafbrydelse. Den ideelle løsning bør tillade regelmæssig test af katastrofegendannelsesprocessen.

Hovedemner for sammenligning

• Datatilgængelighed og konsistens
  • Gtid, scm
  • Nævn replikering til flere standby-, asynkron- og synkroniseringsmodeller
  • Isolering af standby fra produktionsfejl (f.eks. forsinket replikering til mysql)
  • Undgå tab af data (synkroniseringsreplikering)
• Anvendelse af standby-systemer
  • Brug af standby
• Failover, Switchover og automatisk gendannelse
  • Database failover
  • Transparent applikations-failover (TAF vs. ProxySQL, MaxScale)
• Sikkerhed
• Nemhed at bruge og administrere (ensartet styring af præ-integrerede komponenter)

Datatilgængelighed og konsistens

MySQL GTID

MySQL 5.5-replikering var baseret på binære loghændelser, hvor alt en slave vidste var den præcise hændelse og den nøjagtige position, den lige læste fra masteren. Enhver enkelt transaktion fra en master kan være endt i forskellige binære logfiler fra forskellige slaver, og transaktionen vil typisk have forskellige positioner i disse logfiler. Det var en simpel løsning, der kom med begrænsninger, topologiændringer kunne kræve, at en administrator stopper replikering på de involverede instanser. Disse ændringer kan forårsage nogle andre problemer, f.eks. kunne en slave ikke flyttes ned i replikeringskæden uden en tidskrævende genopbygning. Reparation af et brudt replikeringslink ville kræve manuelt at bestemme en ny binær logfil og positionen for den sidst udførte transaktion på slaven og genoptage derfra, eller en total genopbygning. Vi har alle været nødt til at omgå disse begrænsninger, mens vi drømmer om en global transaktions-id.

MySQL version 5.6 (og MariaDB version 10.0.2) introducerede en mekanisme til at løse dette problem. GTID (Global Transaction Identifier) ​​giver bedre kortlægning af transaktioner på tværs af noder.

Med GTID kan slaver se en unik transaktion, der kommer ind fra flere mastere, og denne kan nemt tilknyttes slaveudførelseslisten, hvis den skal genstarte eller genoptage replikering. Så rådet er altid at bruge GTID. Bemærk, at MySQL og MariaDB har forskellige GTID-implementeringer.

Oracle SCN

I 1992 med udgivelsen 7.3 introducerede Oracle en løsning til at holde en synkroniseret kopi af en database som standby, kendt som Data Guard fra version 9i release 2. En Data Guard-konfiguration består af to hovedkomponenter, en enkelt primær database og en standby-database (op til 30). Ændringer på den primære database sendes gennem standbydatabasen, og disse ændringer anvendes på standbydatabasen for at holde den synkroniseret.

Oracle Data Guard oprettes oprindeligt ud fra en sikkerhedskopi af den primære database. Data Guard synkroniserer automatisk den primære database og alle standby-databaser ved at overføre den primære database-redo - informationen, der bruges af hver Oracle-database til at beskytte transaktioner - og anvende den på standby-databasen. Oracle bruger en intern mekanisme kaldet SCN (System Change Number). System Change Number (SCN) er Oracles ur, hver gang vi forpligter os, stiger uret. SCN markerer et konsistent tidspunkt i databasen, som er et kontrolpunkt, der er handlingen med at skrive beskidte blokke (modificerede blokke fra buffercachen til disken). Vi kan sammenligne det med GTID i MySQL.

Data Guard-transporttjenester håndterer alle aspekter af overførsel af redo fra en primær til en standby-database. Efterhånden som brugere foretager transaktioner på den primære, genereres genoptagelsesposter og skrives til en lokal online logfil. Data Guard-transporttjenester transmitterer samtidigt den samme redo direkte fra den primære databaselogbuffer (hukommelsen allokeret inden for systemets globale område) til standbydatabasen(-erne), hvor den skrives til en standby-redo-logfil.

Der er et par hovedforskelle mellem MySQL-replikering og Data Guard. Data Guards direkte transmission fra hukommelsen undgår disk I/O-overhead på den primære database. Det er forskelligt fra, hvordan MySQL fungerer - læsning af data fra hukommelsen reducerer I/O på en primær database.

Data Guard sender kun databaseredo. Det er i skarp kontrast til fjernspejling af lager, som skal transmittere hver ændret blok i hver fil for at opretholde synkronisering i realtid.

Async + Sync-modeller

Oracle Data Guard tilbyder tre forskellige modeller til genanvendelse. Adaptive modeller afhænger af tilgængelig hardware, processer og i sidste ende forretningsbehov.

• Maksimal ydeevne - standarddriftstilstand, der tillader en transaktion at udføre, så snart de gentag-data, der er nødvendige for at gendanne den pågældende transaktion, er skrevet til den lokale redo-log på masteren.
• Maksimal beskyttelse - intet datatab og det maksimale beskyttelsesniveau. De redo-data, der er nødvendige for at forbedre hver operation, skal skrives til både den lokale online-redo-log på masteren og standby-redo-log på mindst én standby-database, før transaktionen forpligtes (Oracle anbefaler mindst to standbys). Den primære database vil lukke ned, hvis en fejl blokerer den i at skrive dens gentage-stream til mindst én synkroniseret standby-database.
• Maksimal tilgængelighed - ligner Maksimal beskyttelse, men den primære database lukkes ikke ned, hvis en fejl forhindrer den i at skrive sin gen-strøm.

Når det kommer til at vælge dit MySQL-replikeringsopsætning, har du valget mellem asynkron replikering eller semi-synkron replikering.

• Asynchronous binlog application er standardmetoden til MySQL-replikering. Masteren skriver hændelser til sin binære log, og slaver anmoder om dem, når de er klar. Der er ingen garanti for, at nogen begivenhed nogensinde vil nå nogen slave.
• Semi-synkron commit på primær er forsinket, indtil master modtager en bekræftelse fra den semi-synkrone slave om, at data modtages og skrives af slaven. Bemærk venligst, at semi-synkron replikering kræver et ekstra plugin for at blive installeret.

Udnyttelse af standby-systemer

MySQL er kendt for sin replikeringsenkelhed og fleksibilitet. Som standard kan du læse eller endda skrive til dine standby-/slaveservere. Heldigvis bragte MySQL 5.6 og 5.7 mange væsentlige forbedringer til replikering, herunder Global Transaction ID'er, hændelseskontrolsummer, multi-threaded slaves og crash-sikre slaves/masters for at gøre det endnu bedre. DBA'er, der er vant til at læse og skrive MySQL-replikering, ville forvente en lignende eller endda enklere løsning fra sin storebror, Oracle. Desværre ikke som standard.

Den fysiske standard-standby-implementering for Oracle er lukket for alle læse-skrive-operationer. Faktisk tilbyder Oracle logisk variation, men det har mange begrænsninger, og det er ikke designet til HA. Løsningen på dette problem er en ekstra betalt funktion kaldet Active Data Guard, som du kan bruge til at læse data fra standby, mens du anvender redo-logs.

Active Data Guard er en betalt tilføjelsesløsning til Oracles gratis Data Guard-katastrofegendannelsessoftware, der kun er tilgængelig for Oracle Database Enterprise Edition (den højeste prislicens). Den leverer skrivebeskyttet adgang, mens den løbende anvender ændringer sendt fra den primære database. Som en aktiv standby-database hjælper den med at aflæse læseforespørgsler, rapportering og trinvise sikkerhedskopier fra den primære database. Produktets arkitektur er designet til at tillade standby-databaser at blive isoleret fra fejl, der kan opstå i den primære database.

En spændende funktion ved Oracle database 12c og noget, som Oracle DBA ville savne, er valideringen af ​​datakorruption. Korruptionstjek af Oracle Data Guard udføres for at sikre, at data er i nøjagtig justering, før data kopieres til en standby-database. Denne mekanisme kan også bruges til at gendanne datablokke på den primære direkte fra standby-databasen.

Failover, Switchover og Automatisk gendannelse

For at holde din replikeringsopsætning stabil og kørende, er det afgørende, at systemet er modstandsdygtigt over for fejl. Fejl skyldes enten softwarefejl, konfigurationsproblemer eller hardwareproblemer og kan opstå når som helst. Hvis en server går ned, skal du have en alarmmeddelelse om den forringede opsætning. Failover (forfremmelse af en slave til master) kan udføres af administratoren, som skal beslutte, hvilken slave der skal forfremmes.

Administratoren har brug for information om fejlen, synkroniseringsstatus i tilfælde af at nogen data vil gå tabt, og endelig trin til at udføre handlingen. Ideelt set bør alt være automatiseret og synligt fra en enkelt konsol.

Der er to hovedtilgange til MySQL failover, automatisk og manuel. Begge muligheder har sine fans, vi beskriver begreberne i en anden artikel.

Med GTID'et bliver den manuelle failover meget lettere. Den består af trin som:

• Stop modtagermodulet (STOP SLAVE IO_THREAD)
• Skift master (SKIFT MASTER TIL )
• Start modtagermodulet (START SLAVE IO_THREAD)

Oracle Data Guard kommer med en dedikeret failover/switchover-løsning - Data Guard Broker. Mægleren er en distribueret administrationsramme, der automatiserer og centraliserer oprettelsen, vedligeholdelsen og overvågningen af ​​Oracle Data Guard-konfigurationer. Med adgangen til DG broker-værktøjet kan du udføre konfigurationsændringer, switchovers, failovers og endda tørtest af dit høje tilgængelighedsopsætning. De to hovedhandlinger er:

• Kommandoen SWITCHOVER TO bruges til at udføre overgangen. Efter den vellykkede overgang skifter databaseforekomster plads, og replikeringen fortsætter. Det er ikke muligt at skifte, når standby ikke reagerer, eller den er nede.
• Den fælles FAILOVER TIL bruges til at udføre failover. Efter failover-handlingen kræver den tidligere primære server genskabelse, men den nye primære kan tage databasens arbejdsbyrde.

Når vi taler om failover, er vi nødt til at overveje, hvor problemfri din applikations-failover kan være. I tilfælde af et planlagt/uplanlagt afbrydelse, hvor effektivt kan brugersessioner dirigeres til et sekundært websted med minimal forretningsafbrydelse.

Standardtilgangen til MySQL ville være at bruge en af ​​de tilgængelige Load Balancers. Startende fra HAProxy, som er meget udbredt til HTTP eller TCP/IP failover, til databasebevidst Maxscale eller ProxySQL.

I Oracle løses dette problem af TAF (Transparent Application Failover). Når omstillingen eller failover sker, dirigeres applikationen automatisk til den nye primære. TAF gør det muligt for applikationen automatisk og gennemsigtigt at oprette forbindelse til en ny database, hvis databaseinstansen, som forbindelsen oprettes til, mislykkes.

Sikkerhed

Datasikkerhed er et varmt problem for mange organisationer i disse dage. For dem, der har brug for at implementere standarder som PCI DSS eller HIPAA, er databasesikkerhed et must. De tværgående WAN-miljøer kan føre til bekymringer om databeskyttelse og sikkerhed, især da flere virksomheder er nødt til at overholde nationale og internationale regler. MySQL binære logfiler, der bruges til replikering, kan indeholde letlæselige følsomme data. Med standardkonfigurationen er det en meget nem proces at stjæle data. MySQL understøtter SSL som en mekanisme til at kryptere trafik både mellem MySQL-servere (replikering) og mellem MySQL-servere og klienter. En typisk måde at implementere SSL-kryptering på er at bruge selvsignerede certifikater. Det meste af tiden er det ikke nødvendigt at få et SSL-certifikat udstedt af certifikatmyndigheden. Du kan enten bruge openssl til at oprette certifikater, f.eks. nedenfor:

$ 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

Rediger derefter replikering med parametre for 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';

For mere automatiseret mulighed kan du bruge ClusterControl til at aktivere kryptering og administrere SSL-nøgler.

I Oracle 12c kan Data Guard redo-transport integreres med et sæt dedikerede sikkerhedsfunktioner kaldet Oracle Advanced Security (OAS). Avanceret sikkerhed kan bruges til at aktivere kryptering og godkendelsestjenester mellem det primære og standby-system. For eksempel kræver aktivering af Advanced Encryption Standard (AES) krypteringsalgoritme kun nogle få parameterændringer i filen sqlnet.ora for at gøre redo (svarende til MySQL binlog) krypteret. Der kræves ingen ekstern certifikatopsætning, og det kræver kun en genstart af standby-databasen. Ændringen i sqlnet.ora og wallet er enkel som:

Opret et tegnebogsmappe

mkdir /u01/app/wallet

Rediger sqlnet.ora

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

Opret et nøglelager

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

Åbn butik

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Opret en hovednøgle

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

På standby

kopier p12- og .sso-filer i tegnebogens bibliotek og for at opdatere filen sqlnet.ora svarende til den primære node.

For mere information, følg venligst Oracles TDE-hvidbog, du kan lære fra hvidbogen, hvordan du krypterer datafiler og gør tegnebogen altid åben.

Anvendelse og administration

Når du administrerer eller implementerer Oracle Data Guard-konfiguration, kan du finde ud af, at der er mange trin og parametre, du skal kigge efter. For at svare på det oprettede Oracle DG Broker.

Du kan helt sikkert oprette en Data Guard-konfiguration uden at implementere DG Broker, men det kan gøre dit liv meget mere behageligt. Når det er implementeret, er mæglerens kommandolinjeværktøj - DGMGRL sandsynligvis det primære valg for DBA. For dem, der foretrækker GUI, har Cloud Control 13c mulighed for at få adgang til DG Broker via webgrænsefladen.

De opgaver, som Broker kan hjælpe med, er en automatisk start af den administrerede gendannelse, én kommando til failover/switchover, overvågning af DG-replikering, konfigurationsverifikation og mange andre.

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 tilbyder ikke en lignende løsning som Oracle DG Broker. Du kan dog udvide dens funktionalitet ved at bruge værktøjer som Orchestrator, MHA og load balancers (ProxySQL, HAProxy eller Maxscale). Løsningen til at administrere databaser og load balancere er ClusterControl. ClusterControl Enterprise Edition giver dig et komplet sæt administrations- og skaleringsfunktioner ud over de implementerings- og overvågningsfunktioner, der tilbydes som en del af den gratis Community Edition.