Att migrera från Oracle-databas till öppen källkod kan ge ett antal fördelar. Den lägre ägandekostnaden är frestande och driver många företag att migrera. Samtidigt måste DevOps, SysOps eller DBA hålla snäva SLA:er för att möta affärsbehov.
En av de viktigaste frågorna när du planerar datamigrering till en annan databas, särskilt öppen källkod, är hur man undviker dataförlust. Det är inte för långsökt att någon av misstag raderade en del av databasen, någon glömde att inkludera en WHERE-sats i en DELETE-fråga eller köra DROP TABLE av misstag. Frågan är hur man återhämtar sig från sådana situationer.
Sådana saker kan och kommer att hända, det är oundvikligt men konsekvenserna kan bli katastrofala. Som någon sa, "Allt är roligt och spel tills säkerhetskopieringen misslyckas". Den mest värdefulla tillgången kan inte äventyras. Period.
Rädslan för det okända är naturlig om du inte är bekant med ny teknik. Faktum är att kunskapen om Oracles databaslösningar, tillförlitlighet och fantastiska funktioner som Oracle Recovery Manager (RMAN) erbjuder kan avskräcka dig eller ditt team från att migrera till ett nytt databassystem. Vi gillar att använda saker vi kan, så varför migrera när vår nuvarande lösning fungerar. Vem vet hur många projekt som lades på is eftersom teamet eller individen inte var övertygad om den nya tekniken?
Logiska säkerhetskopior (exp/imp, expdp/impdb)
Enligt MySQL-dokumentationen är logisk säkerhetskopiering "en säkerhetskopia som återger tabellstruktur och data, utan att kopiera de faktiska datafilerna." Denna definition kan gälla både MySQL- och Oracle-världar. Detsamma är "varför" och "när" du kommer att använda den logiska säkerhetskopian.
Logiska säkerhetskopior är ett bra alternativ när vi vet vilka data som kommer att ändras så att du bara kan säkerhetskopiera den del du behöver. Det förenklar potentiell återställning när det gäller tid och komplexitet. Det är också mycket användbart om vi behöver flytta en del av små/medelstora datamängder och kopiera tillbaka till ett annat system (ofta på en annan databasversion). Oracle använder exportverktyg som exp och expdp för att läsa databasdata och exportera dem sedan till en fil på operativsystemnivå. Du kan sedan importera tillbaka data till en databas med hjälp av importverktygen imp eller impdp.
Oracle Export Utilities ger oss många alternativ att välja vilken data som behöver exporteras. Du kommer definitivt inte hitta samma antal funktioner med mysql, men de flesta av behoven täcks och resten kan göras med ytterligare skript eller externa verktyg (kolla mydumper).
MySQL kommer med ett paket med verktyg som erbjuder mycket grundläggande funktionalitet. De är mysqldump, mysqlpump (den moderna versionen av mysqldump som har inbyggt stöd för parallellisering) och MySQL-klient som kan användas för att extrahera data till en platt fil.
Nedan hittar du flera exempel på hur du använder dem:
Endast säkerhetskopierad databasstruktur
mysqldump --no-data -h localhost -u root -ppassword mydatabase > mydatabase_backup.sqlBackup-tabellstruktur
mysqldump --no-data --single- transaction -h localhost -u root -ppassword mydatabase table1 table2 > mydatabase_backup.sqlSäkerhetskopiera specifika rader
mysqldump -h localhost --single- transaction -u root -ppassword mydatabase table_name --where="date_created='2019-05-07'" > table_with_specific_rows_dump.sqlImportera tabellen
mysql -u username -p -D dbname < tableName.sqlKommandot ovan kommer att stoppa laddningen om ett fel uppstår.
Om du laddar data direkt från mysql-klienten kommer felen att ignoreras och klienten fortsätter
mysql> source tableName.sqlFör att logga utdata måste du använda
mysql> tee import_tableName.logDu kan hitta alla flaggor förklarade under länkarna nedan:
- 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
Om du planerar att använda logisk säkerhetskopiering över olika databasversioner, se till att du har rätt sorteringsinställning. Följande sats kan användas för att kontrollera standardteckenuppsättningen och sorteringen för en given databas:
USE mydatabase;
SELECT @@character_set_database, @@collation_database;Ett annat sätt att hämta systemvariabeln collation_database är att använda SHOW VARIABLES.
SHOW VARIABLES LIKE 'collation%';På grund av begränsningarna för mysql-dumpen måste vi ofta ändra utdata. Ett exempel på sådan modifiering kan vara ett behov av att ta bort några rader. Lyckligtvis har vi flexibiliteten att visa och ändra utdata med vanliga textverktyg innan vi återställer. Verktyg som awk, grep, sed kan bli din vän. Nedan är ett enkelt exempel på hur man tar bort den tredje raden från dumpfilen.
sed -i '1,3d' file.txtMöjligheterna är oändliga. Detta är något som vi inte hittar med Oracle eftersom data skrivs i binärt format.
Det finns några saker du måste tänka på när du kör logisk mysql. En av huvudbegränsningarna är rent stöd för parallellism och objektlåsning.
Logiska säkerhetskopieringsöverväganden
När sådan säkerhetskopiering utförs kommer följande steg att utföras.
- LÅS TABELL tabell.
- VISA SKAPA TABELL-tabell.
- VÄLJ * FRÅN tabell TILL OUTFILE temporär fil.
- Skriv innehållet i den temporära filen till slutet av dumpfilen.
- LÅS UPP TABELLER
Som standard inkluderar mysqldump inte rutiner och händelser i dess utdata - du måste uttryckligen ställa in --rutiner och --events-flaggor.
En annan viktig faktor är en motor som du använder för att lagra din data. Förhoppningsvis använder de flesta produktionssystem idag en ACID-kompatibel motor som heter InnoDB. Äldre motor MyISAM var tvungen att låsa alla tabeller för att säkerställa konsekvens. Det var då SPOLA TABELLER MED LÄSSLÅS exekverades. Tyvärr är det det enda sättet att garantera en konsekvent ögonblicksbild av MyISAM-tabeller medan MySQL-servern körs. Detta gör att MySQL-servern blir skrivskyddad tills UNLOCK TABLES exekveras.
För tabeller på InnoDB-lagringsmotorn rekommenderas att använda --single- transaktionsalternativ. MySQL producerar sedan en kontrollpunkt som gör att dumpen kan fånga all data före kontrollpunkten samtidigt som den tar emot inkommande ändringar.
Alternativet --single-transaction i mysqldump gör inte SPOLA TABELLER MED LÄSSLÅS. Det gör att mysqldump ställer in en REPETERBAR LÄS-transaktion för alla tabeller som dumpas.
En mysqldump backup är mycket långsammare än Oracle tools exp, expdp. Mysqldump är ett entrådigt verktyg och detta är dess största nackdel - prestanda är ok för små databaser men det blir snabbt oacceptabelt om datamängden växer till tiotals gigabyte.
- STARTA TRANSAKTIONEN MED KONSISTENT ÖNSKESBILD.
- För varje databasschema och tabell utför en dump dessa steg:
- VISA SKAPA TABELL-tabell.
- VÄLJ * FRÅN tabell TILL OUTFILE temporär fil.
- Skriv innehållet i den temporära filen till slutet av dumpfilen.
- ÅTGÄRDER.
Fysiska säkerhetskopior (RMAN)
Lyckligtvis kan de flesta begränsningarna för logisk säkerhetskopiering lösas med verktyget Percona Xtrabackup. Percona XtraBackup är den mest populära, öppen källkod, MySQL/MariaDB hot backup programvara som utför icke-blockerande säkerhetskopieringar för InnoDB och XtraDB databaser. Den faller inom kategorin fysisk säkerhetskopiering, som består av exakta kopior av MySQL-datakatalogen och filer under den.
Det är samma kategori av verktyg som Oracle RMAN. RMAN kommer som en del av databasprogramvaran, XtraBackup måste laddas ner separat. Xtrabackup är tillgängligt som rpm och deb-paket och stöder endast Linux-plattformar. Installationen är mycket 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 localinstall percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpmXtraBackup låser inte din databas under säkerhetskopieringsprocessen. För stora databaser (100+ GB) ger det mycket bättre återställningstid jämfört med mysqldump. Återställningsprocessen involverar att förbereda MySQL-data från säkerhetskopiorna, innan den ersätts eller byts ut mot den aktuella datakatalogen på målnoden.
Percona XtraBackup fungerar genom att komma ihåg loggsekvensnumret (LSN) när det startar och sedan kopiera bort datafilerna till en annan plats. Att kopiera data tar lite tid och om filerna ändras återspeglar de tillståndet i databasen vid olika tidpunkter. Samtidigt kör XtraBackup en bakgrundsprocess som håller ett öga på transaktionsloggfilerna (aka redo log) och kopierar ändringar från den. Detta måste göras kontinuerligt eftersom transaktionsloggarna är skrivna på ett round-robin-sätt och kan återanvändas efter ett tag. XtraBackup behöver transaktionsloggposterna för varje ändring av datafilerna sedan den började köras.
När XtraBackup är installerat kan du äntligen utföra dina första fysiska säkerhetskopieringar.
xtrabackup --user=root --password=PASSWORD --backup --target-dir=/u01/backups/Ett annat användbart alternativ som MySQL-administratörer gör är att streama backup till en annan server. Sådan stream kan utföras med hjälp av verktyget xbstream, som i exemplet nedan:
Starta en lyssnare på den externa servern på den föredragna porten (i detta exempel 1984)
nc -l 1984 | pigz -cd - | pv | xbstream -x -C /u01/backupsKör säkerhetskopiering och överför till en extern värd
innobackupex --user=root --password=PASSWORD --stream=xbstream /var/tmp | pigz | pv | nc external_host.com 1984Som du kanske märker är återställningsprocessen uppdelad i två huvudsteg (liknande Oracle). Stegen återställs (kopiera tillbaka) och återställning (tillämpa logg).
XtraBackup --copy-back --target-dir=/var/lib/data
innobackupex --apply-log --use-memory=[values in MB or GB] /var/lib/dataSkillnaden är att vi bara kan utföra återställning till den punkt då säkerhetskopian togs. För att tillämpa ändringar efter säkerhetskopieringen måste vi göra det manuellt.
Point in Time Restore (RMAN-återställning)
I Oracle gör RMAN alla steg när vi utför återställning av databasen. Det kan göras antingen till SCN eller tid eller baserat på säkerhetskopieringsdatauppsättningen.
RMAN> run
{
allocate channel dev1 type disk;
set until time "to_date('2019-05-07:00:00:00', 'yyyy-mm-dd:hh24:mi:ss')";
restore database;
recover database; }I mysql behöver vi ett annat verktyg att utföra för att extrahera data från binära loggar (liknande Oracles arkivloggar) mysqlbinlog. mysqlbinlog kan läsa de binära loggarna och konvertera dem till filer. Vad vi behöver göra är
Den grundläggande proceduren skulle vara
- Återställ fullständig säkerhetskopia
- Återställ inkrementella säkerhetskopior
- För att identifiera start- och sluttider för återställning (det kan vara slutet av säkerhetskopieringen och positionsnumret innan tabell tyvärr släpps).
- Konvertera nödvändiga bingloggar till SQL och använd nyskapade SQL-filer i rätt ordning - se till att köra ett enda mysqlbinlog-kommando.
> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p
Kryptera säkerhetskopior (Oracle Wallet)
Percona XtraBackup kan användas för att kryptera eller dekryptera lokala eller strömmande säkerhetskopior med xbstream-alternativet för att lägga till ytterligare ett lager av skydd till säkerhetskopiorna. Både --encrypt-key option och --encryptkey-file kan användas för att ange krypteringsnyckeln. Krypteringsnycklar kan genereras med kommandon som
$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1Detta värde kan sedan användas som krypteringsnyckel. Exempel på kommandot innobackupex som använder --encrypt-key:
$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encryptedFör att dekryptera, använd helt enkelt --decrypt-alternativet med lämplig --encrypt-key:
$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2019-05-08_11-10-09/Reservpolicy
Det finns ingen inbyggd säkerhetskopieringspolicy vare sig i MySQL/MariaDB eller till och med Perconas verktyg. Om du vill hantera dina MySQL logiska eller fysiska säkerhetskopior kan du använda ClusterControl för det.
ClusterControl är det allomfattande databashanteringssystemet med öppen källkod för användare med blandade miljöer. Den tillhandahåller avancerad säkerhetskopieringshanteringsfunktion för MySQL eller MariaDB.
Med ClusterControl kan du:
- Skapa säkerhetskopieringspolicyer
- Övervaka säkerhetskopieringsstatus, körningar och servrar utan säkerhetskopior
- Utför säkerhetskopieringar och återställningar (inklusive en tidpunktsåterställning)
- Styra lagring av säkerhetskopior
- Spara säkerhetskopior i molnlagring
- Validera säkerhetskopior (fullständigt test med återställningen på den fristående servern)
- Kryptera säkerhetskopior
- Komprimera säkerhetskopior
- Och många andra
ClusterControl:Backup Management Behåll säkerhetskopior i molnet
Organisationer har historiskt implementerat lösningar för säkerhetskopiering av band som ett sätt att skydda
data från fel. Men framväxten av public cloud computing har också möjliggjort nya modeller med lägre TCO än vad som traditionellt varit tillgängligt. Det är ingen affärsmässig mening att ta bort kostnaden för en DR-lösning från designen av den, så organisationer måste implementera rätt skyddsnivå till lägsta möjliga kostnad.
Molnet har förändrat säkerhetskopieringsbranschen. På grund av dess överkomliga prispunkt har mindre företag en offsite-lösning som säkerhetskopierar all deras data (och ja, se till att den är krypterad). Både Oracle och MySQL erbjuder inte inbyggda molnlagringslösningar. Istället kan du använda verktygen som tillhandahålls av molnleverantörer. Ett exempel här kan vara s3.
aws s3 cp severalnines.sql s3://severalnine-sbucket/mysql_backupsSlutsats
Det finns ett antal sätt att säkerhetskopiera din databas, men det är viktigt att se över affärsbehov innan du bestämmer dig för en säkerhetskopieringsstrategi. Som du kan se finns det många likheter mellan MySQL- och Oracle-säkerhetskopior som förhoppningsvis kan möta dina SLA:er.
Se alltid till att du tränar dessa kommandon. Inte bara när du är ny på tekniken utan när DBMS blir oanvändbart så att du vet vad du ska göra.
Om du vill lära dig mer om MySQL, vänligen kolla vårt whitepaper The DevOps Guide to Database Backups for MySQL and MariaDB.