Sammenligning af replikeringsløsninger fra Oracle og MySQL

Databaser kan fejle uden varsel - enten på grund af et nedbrud forårsaget af en softwarefejl eller de underliggende hardwarekomponenter. Skyen bringer en anden dimension til problemet på grund af den flygtige natur af computer- og lagerressourcer. For at isolere vores databaseinfrastruktur fra disse fejl, indbygger vi redundans i vores systemer. Hvis en instans bliver utilgængelig, bør et standby-system være i stand til at tage arbejdsbyrden og fortsætte derfra. Replikering er en velkendt og udbredt metode til at skabe redundante kopier af en masterdatabase.

I dette indlæg skal vi sammenligne replikeringsfunktionaliteten i de to mest populære databasesystemer på planeten (ifølge db-engines) - Oracle og MySQL. Vi vil specifikt se på Oracle 12c logisk replikering og MySQL 5.7. Begge teknologier tilbyder pålidelige standby-systemer til at aflaste produktionsbelastninger og hjælpe i tilfælde af en katastrofe. Vi vil tage et kig på deres forskellige arkitekturer, analysere fordele og ulemper og gennemgå trinene til, hvordan du opsætter replikering med Oracle og MySQL.

Oracle Data Guard Architecture – Sådan fungerer det

Oracle Data Guard sikrer høj tilgængelighed, databeskyttelse og katastrofegendannelse af dine data. Det er sandsynligvis en Oracle DBA's førstevalg til replikering af data. Teknologien blev introduceret i 1990 (version 7.0) med en væsentlig anvendelse af arkivlogfiler på standby-databaser. Data Guard har udviklet sig gennem årene og leverer nu et omfattende sæt tjenester, der opretter, vedligeholder, administrerer og overvåger standby-databaser.

Data Guard vedligeholder standby-databaser som kopier af produktionsdatabasen. Hvis den primære database holder op med at reagere, kan Data Guard skifte enhver standby til produktionsrollen og dermed nedetid. Data Guard kan bruges til sikkerhedskopiering, gendannelse og klyngeteknikker for at give et højt niveau af databeskyttelse og datatilgængelighed.

Data Guard er en Ship Redo / Apply Redo-teknologi, "redo" er den information, der er nødvendig for at gendanne transaktioner. En produktionsdatabase, der omtales som en primær database, sender om til en eller flere replikaer, der kaldes standby-databaser. Når der foretages en indsættelse eller opdatering af en tabel, fanges denne ændring af logskriveren i en arkivlog og replikeres til standbysystemet. Standby-databaser er i en kontinuerlig fase med gendannelse, verificering og anvendelse af gentag for at opretholde synkronisering med den primære database. En standby-database vil også automatisk synkronisere igen, hvis den midlertidigt afbrydes til den primære på grund af strømafbrydelser, netværksproblemer osv.

Data Guard Redo Transport Services regulerer transmissionen af ​​redo fra den primære database til standby-databasen. LGWR-processen (log writer) sender redo-dataene til en eller flere netværksserverprocesser (LNS1, LSN2, LSN3, ...LSNn). LNS læser fra redo-bufferen i SGA (Shared Global Area) og sender redo til Oracle Net Services for at overføre til standby-databasen. Du kan vælge LGWR-attributterne:synkron (LogXptMode ='SYNC') eller asynkron tilstand (LogXptMode ='ASYNC'). Med en sådan arkitektur er det muligt at levere redo-dataene til flere standby-databaser eller bruge dem med Oracle RAC (Real Application Cluster). Remote File Server (RFS)-processen modtager redo fra LNS og skriver den til en almindelig fil kaldet en standby redo log (SRL) fil.

Der er to hovedtyper af Oracle Data Guard. Fysisk med redo-anvend og logiske standby-databaser med SQL gælder.

SQL-anvendelse kræver mere bearbejdning end redo-anvendelse, processen læser først SRL'en og "miner" den redo ved at konvertere den til logiske ændringsposter, og bygger derefter SQL-transaktioner, før SQL'en anvendes til standby-databasen. Der er flere bevægelige dele, så det kræver mere CPU, hukommelse og I/O, og gentag derefter.

Den største fordel ved "SQL-anvendelse" er, at databasen er åben til at læse-skrive, mens ansøgningsprocessen er aktiv.

Du kan endda oprette visninger og lokale indekser. Dette gør den ideel til rapporteringsværktøjer. Standby-databasen behøver ikke at være én til én kopi af din primære database og er derfor muligvis ikke den bedste kandidat til DR-formål.

Nøglefunktionerne ved denne løsning er:

• En standby-database, der åbnes for læse-skrive, mens SQL Application er aktiv
• Mulig modifikationslås af data, der vedligeholdes af SQL'en, gælder
• Kan udføre rullende databaseopgraderinger

Der er ulemper. Oracle bruger en primær-nøgle eller en unik-begrænsning/indeks supplerende logning til logisk at genkende en ændret række i den logiske standby-database. Når supplerende logning af primærnøgle og unikke begrænsninger/indeks for databasen er aktiveret, skriver hver UPDATE-sætning også de kolonneværdier, der er nødvendige i forny-loggen for entydigt at identificere den ændrede række i den logiske standby-database. Oracle Data Guard understøtter kædet replikering, som her kaldes "kaskade", men det er ikke typisk på grund af kompleksiteten af ​​opsætningen.

Oracle anbefaler, at du tilføjer en primær nøgle eller et ikke-null-entydigt indeks til tabeller i den primære database, når det er muligt, for at sikre, at SQL Apply effektivt kan anvende opdateringer af gendata til den logiske standby-database. Det betyder, at det ikke virker på nogen opsætning, du skal muligvis ændre din applikation.

Oracle Golden Gate Architecture – Sådan fungerer det

Med Data Guard, efterhånden som blokke ændres i databasen, tilføjes poster til redo-loggen. Baseret på den replikeringstilstand, du kører, vil disse logposter enten straks kopieres til standby eller udvindes til SQL-kommandoer og anvendes. Golden Gate fungerer på en anden måde.

Golden Gate replikerer kun ændringer, efter at transaktionen er begået, så hvis du har en langvarig transaktion, kan det tage et stykke tid at replikere. Golden Gate "udtrækningsprocessen" holder transaktionsændringer i hukommelsen.

En anden stor forskel er, at Oracle Golden Gate muliggør udveksling og manipulation af data på transaktionsniveau mellem flere, heterogene platforme. Du er ikke kun begrænset til Oracle-databasen. Det giver dig fleksibiliteten til at udtrække og replikere udvalgte dataposter, transaktionsændringer og ændringer til DDL (data definition language) på tværs af en række topologier.

Det typiske Golden Gate-flow viser nye og ændrede databasedata, der fanges fra kildedatabasen. De opsamlede data skrives til en fil kaldet kildesporet. Sporet læses derefter af en datapumpe, sendes på tværs af netværket og skrives til en ekstern sporfil af Collector-processen. Leveringsfunktionen læser fjernsporet og opdaterer måldatabasen. Hver af komponenterne styres af Manager-processen.

MySQL Logisk replikering – Sådan fungerer det

Replikering i MySQL har eksisteret i lang tid og har udviklet sig gennem årene. Der er forskellige måder at aktivere MySQL-replikering på, herunder Group Replication, Galera Clusters, asynkron "Master to Slave". For at sammenligne Oracle vs. MySQL-arkitektur vil vi fokusere på replikeringsformater, da det er grundlaget for alle de forskellige replikeringstyper.

Først og fremmest svarer de forskellige replikeringsformater til det binære logningsformat, der er angivet i my.cnf-konfigurationsfilen. Uanset formatet gemmes logfiler altid på en binær måde, som ikke kan ses med en almindelig editor. Der er tre formattyper:rækkebaseret, erklæringsbaseret og blandet. Blandet er kombinationen af ​​de to første. Vi vil tage et kig på sætning og række baseret.

Udsagn baseret - i dette tilfælde er det de skriftlige forespørgsler. Ikke alle sætninger, der ændrer data (såsom INSERT DELETE-, UPDATE- og REPLACE-sætninger), kan replikeres ved hjælp af sætningsbaseret replikering. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() osv. vil ikke blive replikeret.

Rækkebaseret – i dette tilfælde er der tale om ændringer af poster. Alle ændringer kan replikeres. Dette er den sikreste form for replikering. Siden 5.7.7 er det standardindstillingen.

Lad os nu tage et kig på, hvad der sker under motorhjelmen, når replikering er aktiveret.

Først og fremmest skriver masterdatabasen ændringer til en fil kaldet binær log eller binlog. At skrive til binær log er normalt en letvægtsaktivitet, fordi skrivninger er bufret og sekventielle. Den binære logfil gemmer data, som en replikeringsslave vil behandle senere, masteraktiviteten afhænger ikke af dem. Når replikeringen starter, vil mysql udløse tre tråde. En på herren, to på slaven. Masteren har en tråd, kaldet dump-tråden, der læser masterens binære log og leverer den til slaven.

På slaven forbinder en proces kaldet IO tråd til masteren, læser binære loghændelser fra masteren, når de kommer ind og kopierer dem over til en lokal logfil kaldet relay log. Den anden slaveproces – SQL-tråd – læser hændelser fra en relælog, der er gemt lokalt på replikeringsslaven og bruger dem derefter.

MySQL understøtter kædet replikering, hvilket er meget nemt at konfigurere. Slaver, som også er mastere, skal køre med --log-bin og --log-slave-update parametre.

For at tjekke status for replikationen og få information om tråde, kører du på slaven:

MariaDB [(ingen)]> vis slavestatus\G**************************** 1. række ** ************************* Slave_IO_State:Venter på, at master sender begivenhed 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:Ingen 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:konservativ SQL_Delay:0 SQL_Remaining_Delay:NULL Slave_SQL_Running_State:Slaven har læst al relælog; venter på, at slave-I/O-tråden opdaterer den1 række i sæt (0,00 sek.) 

Opsætning af Data Guard Logical Replication i Oracle

1. Opret en fysisk standby-database

   For at oprette en logisk standbydatabase skal du først oprette en fysisk standbydatabase og derefter overføre den til en logisk standbydatabase.

2. Stop Gentag Anvend på den fysiske standby-database

   Stop Gentag Anvend er nødvendigt for at undgå at anvende ændringer.

   SQL> ALTER DATABASE RECOVER ADMINISTRERET STANDBY DATABASE ANNULLER; 

3. Forbered den primære database til at understøtte en logisk standby-database

   Skift VALID_FOR-attributten i den originale LOG_ARCHIVE_DEST_1 og tilføj LOG_ARCHIVE_DEST_3 til den logiske database.

   LOG_ARCHIVE_DEST_1='LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines'LOG_ARCHIVE_DEST_3='LOCATION=/arch2/severalnines/severalnines/severalnines/Severalnines/Severalnines/FILD_STFORTE_LOGLES_AND_STFORTEN_LOGLES_AND_STFORTE_LOGLES_AND_STFORTE_LOG. AKTIVER 

   Byg en ordbog i Redo Data

   SQL> UDFØR DBMS_LOGSTDBY.BUILD; 

4. Konverter til en logisk standby-database

   For at fortsætte med at anvende redo-data til den fysiske standby-database, indtil den er klar til at konvertere til en logisk standby-database, skal du udstede følgende SQL-sætning:

   SQL> ÆNDRING AF DATABASE TIL LOGISK STANDBY db_name; 

5. Juster initialiseringsparametre for den logiske standby-database

   meget /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_ABLE_3DEST=ENABLELOG_ARCHIVE_3DEST

6. Åbn den logiske standby-database

   SQL> ALTER DATABASE ÅBN RESETLOGS; 

   Bekræft, at den logiske standby-database fungerer korrekt

   v$data_guard_stats-visning

   SQL> COL NAVN FORMAT A20SQL> COL VALUE FORMAT A12SQL> COL ENHED FORMAT A30SQL> VÆLG NAVN, VÆRDI, ENHED FRA V$Data_Guard_STATS; NAVN VÆRDI ENHED--------------------- ------------ --------------- ---------------anvend sluttid +00 00:00:00 dag(2) til sekund(1) interval anvend forsinkelse +00 00:00:00 dag(2) til sekund( 0) intervaltransport lag +00 00:00:00 dag(2) til sekund(0) interval 

   v$logstdby_process-visning

   SQL> KOLONNE SERIE# FORMAT 9999SQL> KOLONNE SID FORMAT 9999SQL> VÆLG SID, SERIE#, SPID, TYPE, HIGH_SCN FRA V$LOGSTDBY_PROCESS; SID SERIE# 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 9 rækker valgt. 

Dette er de nødvendige trin for at skabe Oracle Data Guard logisk replikering. Handlinger vil være lidt anderledes, hvis du udfører denne handling med ikke-standard kompatibilitetssæt eller databaser, der kører i Oracle RAC-miljø.

Opsætning af MySQL-replikering

1. Konfigurer masterdatabase. Indstil unikt server_id, angiv forskellige replikeringslogfiler –log-basename (MariaDB), aktiver binær log. Rediger my.cnf-filen med nedenstående oplysninger.

   log-binserver_id=1log-basename=master1 

   Log ind på masterdatabasen og giv replikeringsbrugeren adgang til masterdata.

   GIV REPLIKATIONSLAVE PÅ *.* TIL replication_user 

2. Start begge servere med GTID'er aktiveret.

   gtid_mode=ONenforce-gtid-consistency=true 

3. Konfigurer slaven til at bruge GTID-baseret autopositionering.

   mysql> SKIFT MASTER TIL> MASTER_HOST =vært,> MASTER_PORT =port,> MASTER_USER =replikeringsbruger,> MASTER_PASSWORD =adgangskode,> MASTER_AUTO_POSITION =1; 

4. Hvis du vil tilføje slave til master med data, skal du tage backup og gendanne den på slaveserveren.

   mysqldump --all-databases --single-transaction --triggers --rutiner --host=127.0.0.1 --user=root --password=rootpassword> dump_replication.sql 

   Log ind på slavedatabasen og udfør:

   slave> tee dump_replication_insert.logslave> source dump_replication.sqlslave> SKIFT MASTER TIL MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="adgangskode ", MASTER_PORT=port, MASTER_AUTO_POSITION =1;