Databaser kan misslyckas utan förvarning - antingen på grund av en krasch orsakad av ett programvarufel eller de underliggande hårdvarukomponenterna. Molnet ger en annan dimension till frågan, på grund av den tillfälliga karaktären hos beräknings- och lagringsresurser. För att isolera vår databasinfrastruktur från dessa fel bygger vi in redundans i våra system. Om en instans blir otillgänglig bör ett standbysystem kunna ta arbetsbördan och fortsätta därifrån. Replikering är en välkänd och allmänt använd metod för att skapa redundanta kopior av en huvuddatabas.
I det här inlägget ska vi jämföra replikeringsfunktionaliteten i de två mest populära databassystemen på planeten (enligt db-motorer) - Oracle och MySQL. Vi kommer specifikt att titta på Oracle 12c logisk replikering och MySQL 5.7. Båda teknologierna erbjuder tillförlitliga standby-system för att avlasta produktionsbelastningar och hjälpa till vid en katastrof. Vi kommer att ta en titt på deras olika arkitekturer, analysera för- och nackdelar och gå igenom stegen för hur man ställer in replikering med Oracle och MySQL.
Oracle Data Guard Architecture – Hur det fungerar
Oracle Data Guard garanterar hög tillgänglighet, dataskydd och katastrofåterställning av dina data. Det är förmodligen en Oracle DBA:s första val för att replikera data. Tekniken introducerades 1990 (version 7.0) med en väsentlig tillämpning av arkivloggar på standby-databaser. Data Guard har utvecklats under åren och tillhandahåller nu en omfattande uppsättning tjänster som skapar, underhåller, hanterar och övervakar standby-databaser.
Data Guard upprätthåller standbydatabaser som kopior av produktionsdatabasen. Om den primära databasen slutar svara kan Data Guard växla valfritt standbyläge till produktionsrollen, alltså stilleståndstid. Data Guard kan användas för säkerhetskopiering, återställning och klustertekniker för att ge en hög nivå av dataskydd och datatillgänglighet.
Data Guard är en Ship Redo / Apply Redo-teknik, "redo" är den information som behövs för att återställa transaktioner. En produktionsdatabas som kallas en primär databas sänder om till en eller flera repliker som kallas standby-databaser. När en infogning eller uppdatering görs i en tabell, fångas denna ändring av loggskrivaren till en arkivlogg och replikeras till standbysystemet. Standby-databaser är i en kontinuerlig återställningsfas, verifiering och tillämpning av redo för att upprätthålla synkronisering med den primära databasen. En standby-databas synkroniseras också automatiskt om den tillfälligt kopplas bort till den primära på grund av strömavbrott, nätverksproblem, etc.
Oracle Data Guard Net Services Data Guard Redo Transport Services reglerar överföringen av redo från den primära databasen till standby-databasen. LGWR-processen (loggskrivare) skickar redo-data till en eller flera nätverksserverprocesser (LNS1, LSN2, LSN3, ...LSNn). LNS läser från redo-bufferten i SGA (Shared Global Area) och skickar redo till Oracle Net Services för att överföra till standby-databasen. Du kan välja LGWR-attribut:synkront (LogXptMode ='SYNC') eller asynkront läge (LogXptMode ='ASYNC'). Med en sådan arkitektur är det möjligt att leverera redo-data till flera standby-databaser eller använda den med Oracle RAC (Real Application Cluster). Processen för fjärrfilserver (RFS) tar emot redogörelsen från LNS och skriver den till en vanlig fil som kallas en SRL-fil (standby redo log).
Det finns två huvudtyper av Oracle Data Guard. Fysisk med redo applicera och logiska standbydatabaser med SQL tillämpas.
Oracle Dataguard Logical Replication-arkitektur SQL-applicering kräver mer bearbetning än redo tillämpas, processen läser först SRL och "miner" redogörelsen genom att konvertera den till logiska ändringsposter, och bygger sedan SQL-transaktioner innan SQL tillämpas på standby-databasen. Det finns fler rörliga delar så det kräver mer CPU, minne och I/O och använd sedan om igen.
Den största fördelen med "SQL applicera" är att databasen är öppen för läs-skriv, medan appliceringsprocessen är aktiv.
Du kan till och med skapa vyer och lokala index. Detta gör den idealisk för rapporteringsverktyg. Standbydatabasen behöver inte vara en till en kopia av din primära databas och är därför kanske inte den bästa kandidaten för DR-ändamål.
De viktigaste funktionerna i denna lösning är:
- En standby-databas som öppnas för läs-skriv medan SQL Application är aktiv
- Möjligt modifieringslås av data som underhålls av SQL tillämpas
- Kan utföra rullande databasuppgraderingar
Det finns nackdelar. Oracle använder en primärnyckel eller tilläggsloggning med unika restriktioner/index för att logiskt känna igen en modifierad rad i den logiska standbydatabasen. När tilläggsloggning med primärnyckel och unika restriktioner/index för databasen är aktiverade, skriver varje UPDATE-sats också de kolumnvärden som är nödvändiga i redo-loggen för att unikt identifiera den modifierade raden i den logiska standby-databasen. Oracle Data Guard stöder kedjad replikering, som här kallas "kaskad", men det är inte typiskt på grund av komplexiteten i installationen.
Oracle rekommenderar att du lägger till en primärnyckel eller ett unikt index som inte är null i tabeller i den primära databasen, närhelst det är möjligt, för att säkerställa att SQL Apply effektivt kan tillämpa uppdateringar av redo-data till den logiska standby-databasen. Det betyder att det inte fungerar på någon konfiguration, du kan behöva ändra din applikation.
Oracle Golden Gate Architecture – Hur det fungerar
Med Data Guard, när block ändras i databasen, läggs poster till i redo-loggen. Baserat på det replikeringsläge som du kör, kommer dessa loggposter antingen att kopieras omedelbart till vänteläge eller utvinnas för SQL-kommandon och tillämpas. Golden Gate fungerar på ett annat sätt.
Golden Gate replikerar bara ändringar efter att transaktionen har genomförts, så om du har en lång pågående transaktion kan det ta ett tag att replikera. Golden Gates "extraheringsprocess" håller transaktionsförändringar i minnet.
En annan stor skillnad är att Oracle Golden Gate möjliggör utbyte och manipulering av data på transaktionsnivå mellan flera heterogena plattformar. Du är inte bara begränsad till Oracle-databasen. Det ger dig flexibiliteten att extrahera och replikera utvalda dataposter, transaktionsändringar och ändringar av DDL (data definition language) över en mängd olika topologier.
Oracle Golden Gate-arkitektur Det typiska Golden Gate-flödet visar att nya och ändrade databasdata hämtas från källdatabasen. Den infångade datan skrivs till en fil som kallas källspåret. Spåret läses sedan av en datapump, skickas över nätverket och skrivs till en fjärrspårfil av Collector-processen. Leveransfunktionen läser fjärrspåret och uppdaterar måldatabasen. Var och en av komponenterna hanteras av Manager-processen.
MySQL logisk replikering – hur det fungerar
Replikering i MySQL har funnits länge och har utvecklats under åren. Det finns olika sätt att aktivera MySQL-replikering, inklusive gruppreplikering, Galera-kluster, asynkron "Master to Slave". För att jämföra Oracle vs. MySQL-arkitektur kommer vi att fokusera på replikeringsformat eftersom det är basen för alla olika replikeringstyper.
Först och främst motsvarar de olika replikeringsformaten det binära loggningsformatet som anges i konfigurationsfilen my.cnf. Oavsett format lagras loggar alltid på ett binärt sätt, inte synliga med en vanlig redigerare. Det finns tre formattyper:radbaserad, uttalandebaserad och blandad. Blandat är kombinationen av de två första. Vi kommer att ta en titt på sats- och radbaserade.
Uttalande baserade – i det här fallet är dessa de skriftliga frågorna. Inte alla satser som ändrar data (som INSERT DELETE, UPDATE och REPLACE-satser) kan replikeras med satsbaserad replikering. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() etc kommer inte att replikeras.
Radbaserat – i det här fallet är dessa ändringar i poster. Alla ändringar kan replikeras. Detta är den säkraste formen av replikering. Sedan 5.7.7 är det standardalternativet.
Låt oss nu ta en titt på vad som händer under huven när replikering är aktiverad.
MySQL-replikeringsarkitektur Först och främst skriver huvuddatabasen ändringar i en fil som kallas binär logg eller binlog. Att skriva till binär logg är vanligtvis en lätt aktivitet eftersom skrivningar är buffrade och sekventiella. Den binära loggfilen lagrar data som en replikeringsslav kommer att bearbeta senare, masteraktiviteten beror inte på dem. När replikeringen startar kommer mysql att trigga tre trådar. En på mastern, två på slaven. Mastern har en tråd, kallad dumptråden, som läser masterns binära logg och levererar den till slaven.
På slaven ansluter en process som kallas IO-tråd till mastern, läser binära logghändelser från mastern när de kommer in och kopierar dem till en lokal loggfil som kallas relälogg. Den andra slavprocessen – SQL-tråd – läser händelser från en relälogg lagrad lokalt på replikeringsslaven och använder dem sedan.
MySQL stöder kedjad replikering, vilket är mycket lätt att installera. Slavar som också är masters måste köras med parametrarna --log-bin och --log-slave-update.
För att kontrollera statusen för replikeringen och få information om trådar, kör du på slaven:
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
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: None
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: 0
Master_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: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)Konfigurera Data Guard Logical Replication i Oracle
-
Skapa en fysisk standby-databas
För att skapa en logisk standbydatabas skapar du först en fysisk standbydatabas och överför den sedan till en logisk standbydatabas.
-
Stoppa Gör om Ansök i databasen för fysisk beredskap
Att stoppa Gör om Apply är nödvändigt för att undvika att tillämpa ändringar.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Förbered den primära databasen för att stödja en logisk standby-databas
Ändra VALID_FOR-attributet i den ursprungliga LOG_ARCHIVE_DEST_1 och lägg till LOG_ARCHIVE_DEST_3 för logisk databas.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLESkapa en ordbok i Gör om data
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Konvertera till en logisk standby-databas
Om du vill fortsätta använda redo-data till den fysiska väntelägesdatabasen tills den är redo att konverteras till en logisk väntelägesdatabas, utfärdar du följande SQL-sats:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Justera initieringsparametrar för den logiska standby-databasen
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Öppna Logical Standby Database
SQL> ALTER DATABASE OPEN RESETLOGS;Verifiera att den logiska standbydatabasen fungerar korrekt
v$data_guard_stats-vy
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalv$logstdby_process view
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> 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 9 rows selected.
Dessa är de nödvändiga stegen för att skapa Oracle Data Guard logisk replikering. Åtgärderna kommer att vara något annorlunda om du utför den här operationen med icke-standardkompatibilitetsuppsättning eller databaser som körs i Oracle RAC-miljö.
Konfigurera MySQL-replikering
-
Konfigurera huvuddatabasen. Ställ in unikt server_id, ange olika replikeringsloggar –log-basename (MariaDB), aktivera binär logg. Ändra filen my.cnf med nedanstående information.
log-bin server_id=1 log-basename=master1Logga in på huvuddatabasen och ge replikeringsanvändare tillgång till masterdata.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Starta båda servrarna med GTID aktiverade.
gtid_mode=ON enforce-gtid-consistency=true -
Konfigurera slaven att använda GTID-baserad autopositionering.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Om du vill lägga till slav till master med data måste du ta backup och återställa den på slavservern.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlLogga in på slavdatabasen och kör:
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;