Migrering fra Oracle-database til open source kan give en række fordele. De lavere omkostninger ved ejerskab er fristende og får mange virksomheder til at migrere. Samtidig har DevOps, SysOps eller DBA's behov for at holde stramme SLA'er for at imødekomme forretningsbehov.
En af de vigtigste bekymringer, når du planlægger datamigrering til en anden database, især open source, er, hvordan man undgår datatab. Det er ikke for langt ude, at nogen ved et uheld slettede en del af databasen, nogen glemte at inkludere en WHERE-sætning i en DELETE-forespørgsel eller køre DROP TABLE ved et uheld. Spørgsmålet er, hvordan man kommer sig over sådanne situationer.
Sådanne ting kan og vil ske, det er uundgåeligt, men virkningen kan være katastrofal. Som nogen sagde, "Det er sjovt og sjovt, indtil backup mislykkes". Det mest værdifulde aktiv kan ikke kompromitteres. Periode.
Frygten for det ukendte er naturlig, hvis du ikke er fortrolig med ny teknologi. Faktisk kan kendskabet til Oracle-databaseløsninger, pålidelighed og fantastiske funktioner, som Oracle Recovery Manager (RMAN) tilbyder, afskrække dig eller dit team til at migrere til et nyt databasesystem. Vi kan godt lide at bruge ting, vi kender, så hvorfor migrere, når vores nuværende løsning virker. Hvem ved, hvor mange projekter der blev sat i bero, fordi teamet eller individet ikke var overbevist om den nye teknologi?
Logiske sikkerhedskopier (exp/imp, expdp/impdb)
Ifølge MySQL-dokumentation er logisk backup "en backup, der gengiver tabelstruktur og data uden at kopiere de faktiske datafiler." Denne definition kan gælde for både MySQL- og Oracle-verdener. Det samme er "hvorfor" og "hvornår" du vil bruge den logiske backup.
Logiske sikkerhedskopier er en god mulighed, når vi ved, hvilke data der vil blive ændret, så du kun kan sikkerhedskopiere den del, du har brug for. Det forenkler potentiel gendannelse med hensyn til tid og kompleksitet. Det er også meget nyttigt, hvis vi skal flytte en del af små/mellemstore datasæt og kopiere tilbage til et andet system (ofte på en anden databaseversion). Oracle bruger eksportværktøjer som exp og expdp til at læse databasedata og derefter eksportere dem til en fil på operativsystemniveau. Du kan derefter importere dataene tilbage til en database ved hjælp af importværktøjerne imp eller impdp.
Oracle Export Utilities giver os en masse muligheder for at vælge, hvilke data der skal eksporteres. Du finder bestemt ikke det samme antal funktioner med mysql, men de fleste behov er dækket, og resten kan klares med yderligere scripting eller eksterne værktøjer (tjek mydumper).
MySQL kommer med en pakke af værktøjer, der tilbyder meget grundlæggende funktionalitet. De er mysqldump, mysqlpump (den moderne version af mysqldump, der har indbygget understøttelse af parallelisering) og MySQL-klient, som kan bruges til at udtrække data til en flad fil.
Nedenfor kan du finde flere eksempler på, hvordan du bruger dem:
Kun backup-databasestruktur
mysqldump --no-data -h localhost -u root -ppassword mydatabase> mydatabase_backup.sql Backup tabelstruktur
mysqldump --no-data --single- transaction -h localhost -u root -ppassword mydatabase table1 table2> mydatabase_backup.sql Sikkerhedskopier specifikke rækker
mysqldump -h localhost --single- transaction -u root -ppassword mydatabase table_name --where="date_created='2019-05-07'"> table_with_specific_rows_dump.sql Import af tabellen
mysql -u brugernavn -p -D dbname Ovenstående kommando stopper indlæsningen, hvis der opstår en fejl.
Hvis du indlæser data direkte fra mysql-klienten, vil fejlene blive ignoreret, og klienten fortsætter
mysql> source tableName.sql For at logge output skal du bruge
mysql> tee import_tableName.log Du kan finde alle flag forklaret under nedenstående links:
- https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html
- https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html
- https://dev.mysql.com/doc/refman/8.0/en/mysql.html
Hvis du planlægger at bruge logisk sikkerhedskopiering på tværs af forskellige databaseversioner, skal du sørge for at have den rigtige sorteringsopsætning. Følgende sætning kan bruges til at kontrollere standardtegnsættet og sorteringen for en given database:
BRUG min database;VÆLG @@character_set_database, @@collation_database; En anden måde at hente systemvariablen collation_database på er at bruge SHOW VARIABLES.
VIS VARIABLER SOM 'collation%'; På grund af begrænsningerne i mysql-dumpen er vi ofte nødt til at ændre outputtet. Et eksempel på en sådan modifikation kan være et behov for at fjerne nogle linjer. Heldigvis har vi fleksibiliteten til at se og ændre outputtet ved hjælp af standardtekstværktøjer før gendannelse. Værktøjer som awk, grep, sed kan blive din ven. Nedenfor er et simpelt eksempel på, hvordan man fjerner den tredje linje fra dump-filen.
sed -i '1,3d' file.txt Mulighederne er uendelige. Dette er noget, som vi ikke finder med Oracle, da data er skrevet i binært format.
Der er et par ting, du skal overveje, når du udfører logisk mysql. En af hovedbegrænsningerne er ren støtte til parallelitet og objektlåsning.
Logiske sikkerhedskopieringsovervejelser
Når en sådan sikkerhedskopiering udføres, udføres følgende trin.
- LÅS TABEL tabel.
- VIS Tabel OPRET TABEL.
- VÆLG * FRA tabel TIL UDFIL midlertidig fil.
- Skriv indholdet af den midlertidige fil til slutningen af dumpfilen.
- LÅS TABEL OP
Som standard inkluderer mysqldump ikke rutiner og hændelser i sit output - du skal udtrykkeligt angive --rutiner og --events flag.
En anden vigtig overvejelse er en motor, som du bruger til at gemme dine data. Forhåbentlig bruger de fleste produktionssystemer i disse dage ACID-kompatibel motor kaldet InnoDB. Ældre motor MyISAM var nødt til at låse alle tabeller for at sikre ensartethed. Dette er, når FLUSH TABLES MED LÆSELÅS blev udført. Desværre er det den eneste måde at garantere et ensartet øjebliksbillede af MyISAM-tabeller, mens MySQL-serveren kører. Dette vil få MySQL-serveren til at blive skrivebeskyttet, indtil UNLOCK TABLES udføres.
For tabeller på InnoDB-lagringsmotor anbefales det at bruge --single- transaktionsmulighed. MySQL producerer derefter et kontrolpunkt, der tillader dumpet at fange alle data før kontrolpunktet, mens det modtager indgående ændringer.
--single-transaction-indstillingen i mysqldump gør ikke FLUSH TABELLER MED LÆSELÅS. Det får mysqldump til at opsætte en GENTAGBAR LÆS-transaktion for alle tabeller, der dumpes.
En mysqldump backup er meget langsommere end Oracle tools exp, expdp. Mysqldump er et enkelt-trådet værktøj, og dette er dets største ulempe - ydeevnen er ok for små databaser, men den bliver hurtigt uacceptabel, hvis datasættet vokser til titusvis af gigabyte.
- START TRANSAKTIONEN MED KONSISTENT SNAPSHOD.
- For hvert databaseskema og -tabel udfører en dump disse trin:
- VIS Tabel OPRET TABEL.
- VÆLG * FRA tabel TIL UDFIL midlertidig fil.
- Skriv indholdet af den midlertidige fil til slutningen af dumpfilen.
- KOMMITTERER.
Fysiske sikkerhedskopier (RMAN)
Heldigvis kan de fleste af begrænsningerne ved logisk backup løses med Percona Xtrabackup-værktøjet. Percona XtraBackup er den mest populære, open source, MySQL/MariaDB hot backup software, der udfører ikke-blokerende sikkerhedskopier til InnoDB og XtraDB databaser. Det falder ind under kategorien fysisk sikkerhedskopiering, som består af nøjagtige kopier af MySQL-datamappen og filer nedenunder.
Det er den samme kategori af værktøjer som Oracle RMAN. RMAN kommer som en del af databasesoftwaren, XtraBackup skal downloades separat. Xtrabackup er tilgængelig som rpm og deb-pakke og understøtter kun Linux-platforme. Installationen er meget enkel:
$ wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-8.0.4/binary/redhat/7/x86_64/percona-XtraBackup-80-8.0.4-1. el7.x86_64.rpm$ yum lokalinstaller percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpm XtraBackup låser ikke din database under sikkerhedskopieringsprocessen. For store databaser (100+ GB) giver det meget bedre gendannelsestid sammenlignet med mysqldump. Gendannelsesprocessen involverer forberedelse af MySQL-data fra sikkerhedskopieringsfilerne, før de erstattes eller skiftes til den aktuelle datamappe på målknuden.
Percona XtraBackup fungerer ved at huske logsekvensnummeret (LSN), når det starter, og derefter kopiere datafilerne til et andet sted. Kopiering af data tager noget tid, og hvis filerne ændrer sig, afspejler de databasens tilstand på forskellige tidspunkter. Samtidig kører XtraBackup en baggrundsproces, der holder øje med transaktionslogfilerne (alias redo log) og kopierer ændringer fra den. Dette skal gøres løbende, fordi transaktionsloggene er skrevet på en round-robin måde og kan genbruges efter et stykke tid. XtraBackup har brug for transaktionslogposterne for hver ændring af datafilerne, siden den begyndte at udføres.
Når XtraBackup er installeret, kan du endelig udføre dine første fysiske sikkerhedskopier.
xtrabackup --user=root --password=PASSWORD --backup --target-dir=/u01/backups/ En anden nyttig mulighed, som MySQL-administratorer gør, er streaming af backup til en anden server. En sådan stream kan udføres ved hjælp af xbstream-værktøjet, som i nedenstående eksempel:
Start en lytter på den eksterne server på den foretrukne port (i dette eksempel 1984)
nc -l 1984 | pigz -cd - | pv | xbstream -x -C /u01/backups Kør backup og overfør til en ekstern vært
innobackupex --user=root --password=PASSWORD --stream=xbstream /var/tmp | pigz | pv | nc external_host.com 1984 Som du måske bemærker, er gendannelsesprocessen opdelt i to store trin (svarende til Oracle). Trinene gendannes (kopi tilbage) og gendannelse (anvend log).
XtraBackup --copy-back --target-dir=/var/lib/datainnobackupex --apply-log --use-memory=[værdier i MB eller GB] /var/lib/data Forskellen er, at vi kun kan udføre gendannelse til det punkt, hvor sikkerhedskopien blev taget. For at anvende ændringer efter sikkerhedskopieringen skal vi gøre det manuelt.
Gendannelse af tidspunkter (RMAN-gendannelse)
I Oracle udfører RMAN alle trinene, når vi udfører gendannelse af databasen. Det kan gøres enten til SCN eller tid eller baseret på backupdatasættet.
RMAN> kør{allokér kanal dev1 type disk;set indtil tiden "to_date('2019-05-07:00:00:00', 'åååå-mm-dd:hh24:mi:ss') ";gendan database;gendan database; } I mysql har vi brug for et andet værktøj til at udtrække data fra binære logfiler (svarende til Oracles arkivlogs) mysqlbinlog. mysqlbinlog kan læse de binære logfiler og konvertere dem til filer. Det, vi skal gøre, er
Den grundlæggende procedure ville være
- Gendan fuld sikkerhedskopi
- Gendan trinvise sikkerhedskopier
- For at identificere start- og sluttidspunkter for gendannelse (det kunne være slutningen af sikkerhedskopieringen og positionsnummeret før du desværre dropper tabellen).
- Konverter nødvendige binglogs til SQL og anvend nyoprettede SQL-filer i den rigtige rækkefølge - sørg for at køre en enkelt mysqlbinlog-kommando.
> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p
Kryptér sikkerhedskopier (Oracle Wallet)
Percona XtraBackup kan bruges til at kryptere eller dekryptere lokale eller streaming backups med xbstream mulighed for at tilføje endnu et lag af beskyttelse til backups. Både --encrypt-key option og --encryptkey-file option kan bruges til at specificere krypteringsnøglen. Krypteringsnøgler kan genereres med kommandoer som
$ openssl rand -base64 24$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1 Denne værdi kan derefter bruges som krypteringsnøgle. Eksempel på kommandoen innobackupex ved hjælp af --encrypt-key:
$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted For at dekryptere skal du blot bruge --decrypt-indstillingen med passende --encrypt-key:
$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”/storage/backups/encrypted/2019-05-08_11-10-09/ Sikkerhedskopieringspolitikker
Der er ingen indbygget sikkerhedskopieringspolitik, hverken i MySQL/MariaDB eller endda Perconas værktøj. Hvis du gerne vil administrere dine MySQL logiske eller fysiske sikkerhedskopier, kan du bruge ClusterControl til det.
ClusterControl er det altomfattende open source-databasestyringssystem til brugere med blandede miljøer. Det giver avanceret backup management funktionalitet til MySQL eller MariaDB.
Med ClusterControl kan du:
- Opret sikkerhedskopieringspolitikker
- Overvåg sikkerhedskopieringsstatus, eksekveringer og servere uden sikkerhedskopier
- Udfør sikkerhedskopier og gendannelser (inklusive et tidspunkt for gendannelse)
- Kontrol tilbageholdelse af backup
- Gem sikkerhedskopier i skylageret
- Valider sikkerhedskopier (fuldstændig test med gendannelsen på den selvstændige server)
- Kryptér sikkerhedskopier
- Komprimer sikkerhedskopier
- Og mange andre
ClusterControl:Backup Management Behold sikkerhedskopier i skyen
Organisationer har historisk set implementeret båndsikkerhedskopieringsløsninger som et middel til at beskytte
data mod fejl. Fremkomsten af public cloud computing har dog også muliggjort nye modeller med lavere TCO end hvad der traditionelt har været tilgængeligt. Det giver ingen forretningsmæssig mening at abstrahere omkostningerne ved en DR-løsning fra designet af den, så organisationer skal implementere det rigtige beskyttelsesniveau til den lavest mulige pris.
Skyen har ændret industrien for databackup. På grund af dets overkommelige prispunkt har mindre virksomheder en offsite-løsning, der sikkerhedskopierer alle deres data (og ja, sørg for, at de er krypteret). Både Oracle og MySQL tilbyder ikke indbyggede cloud storage-løsninger. I stedet kan du bruge værktøjerne fra Cloud-leverandører. Et eksempel her kunne være s3.
aws s3 cp morenines.sql s3://severalnine-sbucket/mysql_backups Konklusion
Der er en række måder at sikkerhedskopiere din database på, men det er vigtigt at gennemgå virksomhedens behov, før du beslutter dig for en backup-strategi. Som du kan se, er der mange ligheder mellem MySQL- og Oracle-sikkerhedskopier, som forhåbentlig kan opfylde dine SLA'er.
Sørg altid for at øve disse kommandoer. Ikke kun når du er ny med teknologien, men når DBMS bliver ubrugelig, så du ved, hvad du skal gøre.
Hvis du gerne vil lære mere om MySQL, så tjek venligst vores hvidbog The DevOps Guide to Database Backups for MySQL og MariaDB.