Databases kunnen zonder waarschuwing falen - hetzij vanwege een crash veroorzaakt door een softwarefout, hetzij door de onderliggende hardwarecomponenten. De cloud voegt een andere dimensie toe aan het probleem, vanwege de kortstondige aard van reken- en opslagbronnen. Om onze database-infrastructuur te isoleren tegen deze storingen, bouwen we redundantie in onze systemen in. Als een instantie niet meer beschikbaar is, moet een stand-bysysteem de werklast kunnen opnemen en van daaruit verder kunnen gaan. Replicatie is een bekende en algemeen aanvaarde methode voor het maken van redundante kopieën van een hoofddatabase.
In dit bericht gaan we de replicatiefunctionaliteit vergelijken in de twee meest populaire databasesystemen ter wereld (volgens db-engines) - Oracle en MySQL. We zullen specifiek kijken naar Oracle 12c logische replicatie en MySQL 5.7. Beide technologieën bieden betrouwbare standby-systemen om productiewerklasten te ontlasten en te helpen bij calamiteiten. We zullen hun verschillende architecturen bekijken, de voor- en nadelen analyseren en de stappen doorlopen voor het instellen van replicatie met Oracle en MySQL.
Oracle Data Guard-architectuur – hoe het werkt
Oracle Data Guard zorgt voor hoge beschikbaarheid, gegevensbescherming en noodherstel van uw gegevens. Het is waarschijnlijk de eerste keuze van een Oracle DBA voor het repliceren van gegevens. De technologie werd geïntroduceerd in 1990 (versie 7.0) met een essentiële toepassing van archieflogboeken op standby-databases. Data Guard is in de loop der jaren geëvolueerd en biedt nu een uitgebreide reeks services voor het maken, onderhouden, beheren en bewaken van stand-bydatabases.
Data Guard onderhoudt standby-databases als kopieën van de productiedatabase. Als de primaire database niet meer reageert, kan Data Guard elke stand-by omschakelen naar de productierol, dus downtime. Data Guard kan worden gebruikt voor back-up-, herstel- en clustertechnieken om een hoog niveau van gegevensbescherming en gegevensbeschikbaarheid te bieden.
Data Guard is een Ship Redo / Apply Redo-technologie, "redo" is de informatie die nodig is om transacties te herstellen. Een productiedatabase die een primaire database wordt genoemd, verzendt opnieuw naar een of meer replica's die stand-bydatabases worden genoemd. Wanneer een tabel wordt ingevoegd of bijgewerkt, wordt deze wijziging door de logboekschrijver vastgelegd in een archieflogboek en gerepliceerd naar het standby-systeem. Standby-databases bevinden zich in een continue fase van herstel, verificatie en opnieuw uitvoeren om de synchronisatie met de primaire database te behouden. Een standby-database wordt ook automatisch opnieuw gesynchroniseerd als deze tijdelijk wordt losgekoppeld van de primaire database vanwege stroomstoringen, netwerkproblemen, enz.
Oracle Data Guard Net Services Data Guard Redo Transport Services regelen de overdracht van redo van de primaire database naar de standby-database. Het LGWR-proces (logboekschrijver) verzendt de herhaalgegevens naar een of meer netwerkserverprocessen (LNS1, LSN2, LSN3, ...LSNn). LNS leest uit de redo-buffer in de SGA (Shared Global Area) en geeft redo door aan Oracle Net Services voor verzending naar de standby-database. U kunt de LGWR-attributen kiezen:synchrone (LogXptMode ='SYNC') of asynchrone modus (LogXptMode ='ASYNC'). Met een dergelijke architectuur is het mogelijk om de redo data aan te leveren aan meerdere standby databases of te gebruiken met Oracle RAC (Real Application Cluster). Het Remote File Server-proces (RFS) ontvangt het opnieuw uitvoeren van LNS en schrijft het naar een normaal bestand dat een stand-by redo-logbestand (SRL) wordt genoemd.
Er zijn twee hoofdtypen Oracle Data Guard. Fysiek met opnieuw toepassen en Logische standby-databases met SQL zijn van toepassing.
Oracle Dataguard Logical Replication-architectuur SQL toepassen vereist meer verwerking dan opnieuw uitvoeren, het proces leest eerst de SRL en "mijn" het opnieuw door het te converteren naar logische wijzigingsrecords, en bouwt vervolgens SQL-transacties voordat de SQL wordt toegepast op de standby-database. Er zijn meer bewegende delen, dus het vereist meer CPU, geheugen en I/O en dan opnieuw toepassen.
Het belangrijkste voordeel van "SQL apply" is dat de database open staat voor lezen en schrijven, terwijl het aanvraagproces actief is.
U kunt zelfs weergaven en lokale indexen maken. Dit maakt het ideaal voor rapportagetools. De standby-database hoeft geen één-op-één kopie van uw primaire database te zijn en is daarom mogelijk niet de beste kandidaat voor DR-doeleinden.
De belangrijkste kenmerken van deze oplossing zijn:
- Een standby-database die wordt geopend voor lezen en schrijven terwijl SQL-toepassing actief is
- Mogelijke wijzigingsvergrendeling van gegevens die door de SQL worden onderhouden, toepassen
- In staat om rolling database-upgrades uit te voeren
Er zijn nadelen. Oracle gebruikt aanvullende logboekregistratie met primaire sleutel of unieke beperking/index om een gewijzigde rij in de logische secundaire database logisch te herkennen. Als aanvullende logboekregistratie voor database-brede primaire sleutel en unieke beperking/index is ingeschakeld, schrijft elke UPDATE-instructie ook de kolomwaarden die nodig zijn in het logboek voor opnieuw uitvoeren om de gewijzigde rij in de logische secundaire database op unieke wijze te identificeren. Oracle Data Guard ondersteunt geketende replicatie, die hier "cascade" wordt genoemd, maar het is niet typisch vanwege de complexiteit van de installatie.
Oracle raadt u aan om waar mogelijk een primaire sleutel of een niet-null unieke index toe te voegen aan tabellen in de primaire database, om ervoor te zorgen dat SQL Apply efficiënt gegevensupdates opnieuw kan toepassen op de logische secundaire database. Dit betekent dat het op geen enkele installatie werkt, het kan zijn dat je je applicatie moet aanpassen.
Oracle Golden Gate Architectuur – Hoe het werkt
Met Data Guard worden records toegevoegd aan het redo-logboek wanneer blokken in de database worden gewijzigd. Vervolgens worden deze logrecords, op basis van de replicatiemodus die u gebruikt, ofwel onmiddellijk gekopieerd naar de stand-by of gedolven voor SQL-opdrachten en toegepast. Golden Gate werkt op een andere manier.
Golden Gate repliceert alleen wijzigingen nadat de transactie is vastgelegd, dus als u een langlopende transactie heeft, kan het even duren om te repliceren. Het "extractieproces" van Golden Gate houdt transactiewijzigingen in het geheugen bij.
Een ander groot verschil is dat Oracle Golden Gate de uitwisseling en manipulatie van gegevens op transactieniveau tussen meerdere, heterogene platforms mogelijk maakt. U bent niet alleen beperkt tot de Oracle-database. Het geeft u de flexibiliteit om geselecteerde gegevensrecords, transactiewijzigingen en wijzigingen in DDL (taal voor gegevensdefinitie) te extraheren en te repliceren in verschillende topologieën.
Oracle Golden Gate-architectuur De typische Golden Gate-stroom laat zien dat nieuwe en gewijzigde databasegegevens worden vastgelegd uit de brondatabase. De vastgelegde gegevens worden weggeschreven naar een bestand dat het bronspoor wordt genoemd. Het spoor wordt vervolgens gelezen door een datapomp, over het netwerk verzonden en door het Collector-proces naar een extern spoorbestand geschreven. De bezorgfunctie leest het externe spoor en werkt de doeldatabase bij. Elk van de componenten wordt beheerd door het Manager-proces.
MySQL Logische replicatie – Hoe het werkt
Replicatie in MySQL bestaat al heel lang en heeft zich in de loop der jaren steeds verder ontwikkeld. Er zijn verschillende manieren om MySQL-replicatie in te schakelen, waaronder groepsreplicatie, Galera-clusters, asynchrone "Master naar Slave". Om Oracle versus MySQL-architectuur te vergelijken, zullen we ons concentreren op replicatie-indelingen, aangezien dit de basis is voor alle verschillende replicatietypen.
Allereerst komen de verschillende replicatieformaten overeen met het binaire logformaat dat is gespecificeerd in het my.cnf-configuratiebestand. Ongeacht het formaat worden logboeken altijd binair opgeslagen en zijn ze niet zichtbaar met een gewone editor. Er zijn drie formaten:op rijen, op verklaringen gebaseerd en gemengd. Gemengd is de combinatie van de eerste twee. We zullen de verklaring en rij bekijken.
Verklaring gebaseerd - in dit geval zijn dit de schriftelijke vragen. Niet alle instructies die gegevens wijzigen (zoals INSERT DELETE-, UPDATE- en REPLACE-instructies) kunnen worden gerepliceerd met replicatie op basis van instructies. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() enz. worden niet gerepliceerd.
Op rijen gebaseerd - in dit geval zijn dit wijzigingen in records. Alle wijzigingen kunnen worden gerepliceerd. Dit is de veiligste vorm van replicatie. Sinds 5.7.7 is dit de standaardoptie.
Laten we nu eens kijken wat er onder de motorkap gebeurt als replicatie is ingeschakeld.
MySQL-replicatie-architectuur Allereerst schrijft de hoofddatabase wijzigingen in een bestand met de naam binary log of binlog. Schrijven naar binair logboek is meestal een lichtgewicht activiteit omdat schrijfacties worden gebufferd en sequentieel zijn. Het binaire logbestand slaat gegevens op die een replicatieslave later zal verwerken, de masteractiviteit is er niet van afhankelijk. Wanneer de replicatie start, zal mysql drie threads activeren. Een op de master, twee op de slave. De master heeft een thread, de dumpthread genaamd, die het binaire logboek van de master leest en aan de slave levert.
Op de slave maakt een proces met de naam IO-thread verbinding met de master, leest binaire loggebeurtenissen van de master zodra ze binnenkomen en kopieert ze naar een lokaal logbestand met de naam relaislog. Het tweede slave-proces – SQL-thread – leest gebeurtenissen uit een relaislogboek dat lokaal op de replicatieslave is opgeslagen en gebruikt ze vervolgens.
MySQL ondersteunt geketende replicatie, wat zeer eenvoudig in te stellen is. Slaves die ook master zijn, moeten draaien met --log-bin en --log-slave-update parameters.
Om de status van de replicatie te controleren en informatie over threads te krijgen, voer je de slave uit:
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)Logische replicatie van Data Guard instellen in Oracle
-
Maak een fysieke standby-database
Om een logische standby-database te maken, maakt u eerst een fysieke standby-database en zet u deze vervolgens over naar een logische standby-database.
-
Stop Opnieuw Toepassen op de fysieke standby-database
Het stoppen van Opnieuw toepassen is nodig om te voorkomen dat wijzigingen worden toegepast.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
De primaire database voorbereiden om een logische stand-bydatabase te ondersteunen
Wijzig het kenmerk VALID_FOR in de oorspronkelijke LOG_ARCHIVE_DEST_1 en voeg LOG_ARCHIVE_DEST_3 toe voor de logische 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/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLEBouw een woordenboek in de gegevens voor opnieuw uitvoeren
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Converteren naar een logische standby-database
Geef de volgende SQL-instructie op om door te gaan met het toepassen van redo-gegevens op de fysieke standby-database totdat deze klaar is om te converteren naar een logische standby-database:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Initialisatieparameters voor de logische stand-bydatabase aanpassen
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 -
Open de logische standby-database
SQL> ALTER DATABASE OPEN RESETLOGS;Controleer of de logische standby-database goed werkt
v$data_guard_stats-weergave
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 weergave
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.
Dit zijn de noodzakelijke stappen om logische replicatie van Oracle Data Guard te maken. De acties zullen iets anders zijn als u deze bewerking uitvoert met een niet-standaard compatibiliteitsset of databases die worden uitgevoerd in een Oracle RAC-omgeving.
MySQL-replicatie instellen
-
Hoofddatabase configureren. Stel unieke server_id in, specificeer verschillende replicatielogboeken –log-basename (MariaDB) , activeer binair logboek. Wijzig mijn.cnf-bestand met onderstaande informatie.
log-bin server_id=1 log-basename=master1Log in op de hoofddatabase en verleen de replicatiegebruiker toegang tot de hoofdgegevens.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Start beide servers met GTID's ingeschakeld.
gtid_mode=ON enforce-gtid-consistency=true -
Configureer de slave om op GTID gebaseerde automatische positionering te gebruiken.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Als je een slaaf aan de master wilt toevoegen met gegevens, dan moet je een back-up maken en deze terugzetten op de slave-server.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlLog in op de slave-database en voer het volgende uit:
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;