Migrera från Oracle Database till MariaDB - Vad du bör veta

Gartner förutspår att år 2022 kommer 50 % av befintliga kommersiella databaser att ha konverterats till databaser med öppen källkod. Ännu mer kommer 70 % av nya interna applikationer att utvecklas på en databasplattform med öppen källkod (State of the Open-Source DBMS Market, 2018).

Dessa är höga siffror med tanke på mognad, stabilitet och kriticitet hos populär, proprietär databasprogramvara. Detsamma kan observeras i den bästa databasen, där de flesta av de tio bästa databaserna är öppen källkod.

Vad är det som driver företag att göra sådana åtgärder?

Det kan finnas många anledningar till att migrera databassystem. För vissa kommer den främsta anledningen att vara kostnaden för licens och ägande; men handlar det egentligen bara om kostnaden? Och är öppen källkod tillräckligt stabil för att flytta kritiska produktionssystem till den nya världen med öppen källkod?

Databaser med öppen källkod, särskilt nya som tagits in i en organisation, kommer ofta från en utvecklare i ett projektteam. Det är valt för att det är gratis (påverkar inte det direkta projektets externa utgifter) och uppfyller de tekniska kraven för tillfället.

Men den fria aspekten kommer faktiskt inte helt enkelt utan kostnad eftersom du måste ta hänsyn till många faktorer, inklusive migreringen och kostnaden för mantimmar. Ju smidigare migrering desto mindre tid och pengar spenderas på projektet.

Databasmigreringar kan vara utmanande, särskilt för heterogena proprietära databasmigreringar som Oracle till PostgreSQL, Oracle till Percona eller MySQL. Den komplexa schemastrukturen, datatyperna och databaskoden som PL/SQL kan skilja sig ganska mycket från måldatabaserna,
och kräver ett schema- och kodtransformationssteg innan datamigreringen startar.

I den senaste artikeln av min kollega Paul Namuag undersökte han hur man migrerar Oracle till Percona.

Den här gången ska vi ta en titt på vad du bör veta innan du migrerar från Oracle till MariaDB.

MariaDB lovar företagsfunktioner och migreringsfunktioner som kan hjälpa till att migrera Oracle-databaser till världen med öppen källkod.

I det här blogginlägget kommer vi att ta upp följande:

• Varför migrera?
• Skillnader i lagringsmotor
• Överväganden om databasanslutning
• Enkel installation och administration
• Säkerhetsskillnader
• Replikering och HA
• PL/SQL och databaskod
• Klustring och skalning
• Säkerhetskopiering och återställning
• Molnkompatibilitet
• Övriga överväganden

Varför migrera från Oracle?

De flesta företag kommer att köra Oracle eller SQL Server, eller en kombination av båda, med små fickor av isolerade databaser med öppen källkod som fungerar oberoende. Små till medelstora företag tenderar att distribuera huvudsakligen databaser med öppen källkod, särskilt för nya applikationer. Men detta håller på att förändras, och ofta är öppen källkod huvudvalet även för stora organisationer.

En snabb jämförelse av dessa två databassystem ser ut som följer:

• Endast Oracle Express Edition är gratis, men den har mycket begränsade funktioner jämfört med MariaDB. För omfattande funktioner måste antingen Oracle Standard Edition eller Oracle Enterprise Edition köpas.
• Å andra sidan arbetade MariaDB och MySQL-communityt hårt för att minimera det potentiella funktionsgapet. Säkerhetsefterlevnad, heta säkerhetskopior och många andra företagsfunktioner är nu tillgängliga i MariaDB.

Det finns saker som alltid var mer flexibla i MariaDB/MySQL än i massiva Oracle-installationer. En av dem är enkel replikering och horisontell klusterskalbarhet.

Skillnader i lagringsmotor

Låt oss först börja med några grunder. Du kan fortfarande höra många legender och myter om MySQL- eller MariaDB-begränsningar, som mestadels hänvisar till de mörka tiderna när huvudlagringsmotorn var MyISAM.

MyISAM var standardlagringsmotorn från MySQL 3.23 tills den ersattes av InnoDB i MariaDB 5.5. Det är en lätt, icke-transaktionell motor med bra prestanda men erbjuder inte låsning på radnivå eller tillförlitligheten hos InnoDB.

Med InnoDB (standardlagringsmotor) erbjuder MariaDB de två standardlåsen på radnivå, som är delade lås(S) och exklusiva lås(X). Ett delat lås erhålls för att läsa en rad och tillåter andra transaktioner att läsa den låsta raden. Olika transaktioner kan också få sina egna delade lås.
Det specifika låset erhålls för att skriva till en rad och hindrar ytterligare transaktioner från att låsa samma rad.

InnoDB har definitivt täckt den största transaktionsfunktionsgapet mellan dessa två system.

På grund av den pluggbara naturen hos MariaDB erbjuder den ännu fler lagringsmotorer så att du bättre kan anpassa den till en specifik arbetsbelastning. d.v.s. När utrymmet är viktigt kan du använda TokuDB som erbjuder utmärkt kompressionsförhållande, Spider optimerad för partitionering och datadelning, ColumnStore för stordataskalning.

Ändå, för de som migrerar från Oracle, skulle min rekommendation vara att gå först med InnoDB-lagringsmotorn.

Anslutningsöverväganden

MariaDB delar med Oracle bra stöd för databasåtkomst inklusive ODBC- och JDBC-drivrutiner, samt åtkomstbibliotek för Perl, Python och PHP. MySQL och Oracle stöder båda binära stora objekt, tecken-, numeriska och datumdatatyper. Så du bör inte ha några problem med att hitta rätt anslutning för dina applikationstjänster.

MariaDB har inte den dedikerade lyssnarprocessen för att upprätthålla databasanslutningar nori SCAN-adress för den klustrade databasen som vi känner till från Oracle. Du hittar inte heller flexibla databastjänster. Istället måste du konfigurera manuellt mellan Unix-socket (ett lokalt, säkraste sätt att ansluta DB - app på samma server), fjärranslutningar (som standard tillåter inte MariaDB fjärrinloggningar) och även pipe och minne tillgängligt på Windows endast system. För klustret måste SCAN-adressen ersättas av lastbalanseraren. MariaDB rekommenderar att du använder deras andra produkt MaxScale, men du kan också hitta andra som ProxySQL eller HAproxy som fungerar med MariaDB, med vissa begränsningar. Även om det kan vara svårt att använda externa belastningsutjämnare för MariaDB kan du hitta fantastiska funktioner som, som jämförelse, inte är tillgängliga i Oracle-databasen.

En lastbalanserare skulle också vara en rekommendation för dem som letar efter Oracle Transparent Application Failover (TAF), Oracle Firewall DB eller några av de avancerade säkerhetsfunktionerna som Oracle Connection Manager. Du kan hitta mer om att välja rätt lastbalanserare i följande vitbok.

Även om dessa tekniker är gratis och kan distribueras manuellt med skriptbaserade installationer, automatiserar system som ClusterControl processen med sitt peka-och-klicka-gränssnitt. ClusterControl låter dig också distribuera cachingteknik.

Enkel installation och administration

Den senaste tillgängliga Oracle DB-versionen lade till en efterlängtad installationsfunktion:Oracle 18c kan nu installeras på Oracle Linux med en RPM. Dedikerad Java-baserad installation var alltid ett problem för dem som ville skriva automatisering för sina kokböcker eller Puppet-kodavsnitt. Du kunde gå med fördefinierad tyst installation men filen ändrades från tid till annan och fortfarande var du tvungen att hantera beroendehelvetet. RPM-baserad installation var definitivt ett bra drag.

Så hur fungerar det i MariaDB?

För dem som flyttar från Oracle-världen är det alltid en trevlig överraskning att se hur snabbt du kan distribuera instanser, skapa nya databaser eller till och med ställa in komplexa replikeringsflöden. Installation och konfigurationsprocessen är förmodligen den smidigaste delen av migreringsprocessen. Även om det tar tid och kunskap att välja rätt inställningar.

Oracle tillhandahåller en uppsättning binära distributioner av MySQL. Dessa inkluderar generiska binära distributioner i form av komprimerade tar-filer (filer med filtillägget .tar.gz) för ett antal plattformar och binärfiler i plattformsspecifika paket. På Windows-plattformen kan du hitta en standardinstallationsguide via ett GUI.

Oracles databaskonfigurationsassistent (DBCA) behövs i princip inte eftersom du kommer att kunna skapa en databas med ett kommando på en rad.

CREATE [OR REPLACE] {DATABASE | SCHEMA} [IF NOT EXISTS] db_name
    [create_specification] ...

create_specification:
    [DEFAULT] CHARACTER SET [=] charset_name
  | [DEFAULT] COLLATE [=] collation_name

Du kan också ha en databas med olika databaskollationer och teckenuppsättningar under samma MariaDB-instans.

Replikeringsinställningen är bara att aktivera binär loggning på en master (liknande arkivloggning i Oracle) och köra följande kommando på slaven för att koppla den till mastern.

CHANGE MASTER TO
MASTER_HOST = host,
MASTER_PORT = port,
MASTER_USER = replication_user,
MASTER_PASSWORD = password,
MASTER_AUTO_POSITION = 1;

Säkerhet och efterlevnad

Oracle tillhandahåller förbättrad databassäkerhet.

Användarautentisering utförs i Oracle genom att ange globala roller utöver plats, användarnamn och lösenord. I Oracle utförs användarautentisering med olika autentiseringsmetoder, inklusive databasautentisering, extern autentisering och proxyautentisering.

Under lång tid var roller inte tillgängliga i MariaDB eller MySQL. MariaDB lade till roller med version 10.2 efter att de dök upp i MySQL 8.0.

Roller, ett alternativ som används flitigt i vanliga Oracle DB-installationer, kan enkelt omvandlas i MariaDB, så att du inte behöver slösa tid på justeringar av enstaka användares behörighet.

Skapa, ändra användare, lösenord:allt fungerar på samma sätt som Oracle DB.

För att uppnå företagssäkerhetsefterlevnadsstandarder erbjuder MariaDB inbyggda funktioner som:

• Revisionsplugin
• Kryptering av data-at-rest
• Certifikat, TSS-anslutning
• PAM-plugin

Revisionspluginerbjudanden en sorts finkornig revision (FGA) eller AUDI SQL tillgänglig i Oracle. Den erbjuder inte samma uppsättning funktioner, men vanligtvis är den tillräckligt bra för att uppfylla granskningar av säkerhetsefterlevnad.

Kryptering av data-at-rest Data i vila kryptering kan vara ett krav för säkerhetsbestämmelser som HIPAA eller PCI DSS. Sådan kryptering kan implementeras på flera nivåer - du kan kryptera hela disken som filerna lagras på. Du kan endast kryptera MySQL-databasen genom funktionalitet som är tillgänglig i de senaste versionerna av MySQL eller MariaDB. Kryptering kan också implementeras i applikationen så att den krypterar data innan den lagras i databasen. Varje alternativ har sina för- och nackdelar:diskkryptering kan bara hjälpa när diskar fysiskt stjäls, men filerna skulle inte krypteras på en databasserver som körs.

PAM-plugin utökar loggningsfunktionen till snäva användarkonton med LDAP-inställningar. Jag tycker faktiskt att det är mycket lättare att installera än LDAP-integration med Oracle Database.

Replikering och HA

MariaDB är välkänt för sin enkelhet och flexibilitet för replikering. Som standard kan du läsa eller till och med skriva till dina standby-/slavservrar. Lyckligtvis medförde MySQL 10.X-versioner många betydande förbättringar av replikering, inklusive globala transaktions-ID:n, händelsekontrollsummor, flertrådiga slavar och kraschsäkra slavar/masters för att göra replikeringen ännu bättre. DBA:er som är vana vid läsning och skrivning av MySQL-replikering skulle förvänta sig en liknande eller till och med enklare lösning från sin storebror Oracle. Tyvärr inte som standard.

Standardimplementeringen för fysisk standby för Oracle är stängd för alla läs- och skrivoperationer. Faktum är att Oracle erbjuder logisk variation men det har många begränsningar, och det är inte designat för HA. Lösningen på det här problemet är en extra betald funktion som kallas Active Data Guard, som du kan använda för att läsa data från vänteläget medan du använder redo-loggar.

Active Data Guard är en betald tilläggslösning till Oracles kostnadsfria Data Guard-programvara för katastrofåterställning som endast är tillgänglig för Oracle Database Enterprise Edition (högsta kostnadslicens). Den ger skrivskyddad åtkomst, samtidigt som ändringar som skickas från den primära databasen tillämpas kontinuerligt. Som en aktiv standby-databas hjälper den till att ladda läsfrågor, rapportering och inkrementella säkerhetskopior från den primära databasen. Produktens arkitektur är utformad för att tillåta standby-databaser att isoleras från fel som kan uppstå i den primära databasen.

En spännande funktion i Oracle-databasen 12c och något som Oracle DBA skulle sakna är valideringen av datakorruption. Korruptionskontroller av Oracle Data Guard utförs för att säkerställa att data är exakt i linje innan data kopieras till en standby-databas. Denna mekanism kan också användas för att återställa datablock på den primära direkt från standby-databasen.

MariaDB erbjuder olika replikeringsmetoder och replikeringsfunktioner som:

• synkron,
• asynkron,
• halvsynkron

Funktionsuppsättningen för MariaDB-replikering är rik. Med synkron replikering kan du ställa in failover utan skrivtransaktionsförlust. För att minska asynkrona replikeringsfördröjningar kanske du vill gå med parallelliserad replikering i ordning på slavar. De händelser som kan komprimeras är de händelser som normalt kan vara av betydande storlek:Frågahändelser (för DDL och DML i satsbaserad replikering) och radhändelser (för DML i radbaserad replikering). I likhet med andra komprimeringsalternativ är MariaDB-komprimerad replikering transparent. Som nämnts tidigare är hela processen mycket enkel jämfört med Oracle Data Guard fysisk och logisk replikering.

PL/SQL och databaskod

Nu kommer vi till den svåra delen:PL/SQL.

Medan replikering och HA med MariaDB regerar. Oracle är kungen av PL/SQL, ingen tvekan där.

PL/SQL är det främsta hindret för migrering till världen med öppen källkod i många organisationer. Men MariaDB ger inte upp här.

MariaDB 10.3 (även känd som MariaDB TX 3.0) har lagt till några fantastiska nya funktioner inklusive SEQUENCE-konstruktioner, paket i Oracle-stil och datatypen ROW – vilket gör migrering mycket enklare.

Med den nya parametern SQL_MODE =ORACLE kan MariaDB nu tolka, beroende på fallet, ett gäng av den äldre Oracle PL/SQL utan att skriva om koden.

Som vi kan hitta på deras kundberättelsesida som använder kärnan Oracle PL/SQL-kompatibilitet i MariaDB TX 3.0, har Development Bank of Singapore (DBS) kunnat migrera mer än hälften av sina affärskritiska applikationer på bara 12 månader från Oracle Databas till MariaDB.

Det nya kompatibilitetsläget hjälper till med följande syntax:

• Slingsyntax
• Variabeldeklaration
• Icke-ANSI lagrad procedurkonstruktion
• Markörsyntax
• Lagrade procedurparametrar
• Arv av datatyp (%TYPE, %ROWTYPE)
• Undantag i PL/SQL-stil
• Synonymer för grundläggande SQL-typer (VARCHAR2, NUMBER, …)

Men om vi tar en titt på den äldre versionen 10.2, såg en del av kompatibiliteten mellan Oracle och MariaDB upp tidigare som:

• Vanliga tabelluttryck
• Rekursiva SQL-frågor
• Windows-funktioner, NTILETE, RANK, DENESE_RANK.

Native PL/SQL-parsning eller i vissa fall kan direkt exekvering av inbyggda Oracle-procedurer avsevärt minska utvecklingskostnaderna.

En annan mycket användbar funktion som lagts till av SQL_MODE=Oracle är sekvenser. Implementeringen av sekvenser i MariaDB Server 10.3 följer SQL:2003-standarden och inkluderar syntaxkompatibilitet med Oracle.

För att skapa en sekvens används en create-sats:

CREATE SEQUENCE Sequence_1 
  START WITH 1  
  INCREMENT BY 1;

När skapade sekvenser kan användas till exempel med inlägg som:

INSERT INTO database (database_id, database_name) VALUES(Sequence_1.NEXTVAL, 'MariaDB');

Klustring och skalning

MariaDB är ett asynkront, aktivt aktivt, multi-master databaskluster.

MariaDB Cluster skiljer sig från det som kallas Oracles MySQL Cluster - NDB.

MariaDB-klustret är baserat på multi-master replikeringsplugin som tillhandahålls av Codership (Galera). Sedan version 5.5 är Galera-tekniken (wsrep API) en integrerad del av MariaDB. Galera plugin-arkitekturen består av tre kärnlager:certifiering, replikering och ramverk för gruppkommunikation.

Certifieringsskiktet förbereder skrivuppsättningarna och gör certifieringskontrollerna av dem, vilket garanterar att de kan appliceras.

Replikeringsskiktet hanterar replikeringsprotokollet och tillhandahåller den totala beställningskapaciteten.

Group Communication Framework implementerar en plugin-arkitektur som tillåter andra system att ansluta via gcomm backend-schema.

Den största skillnaden från Oracle RAC är att varje nod har separerade data. Oracle RAC uppfattas ofta som en kompletterande HA-lösning medan diskar vanligtvis finns i samma diskarray. MariaDB erbjuder inte bara redundant lagring utan stöder också geografiskt placerad klustring utan behov av dedikerad fiber.

Säkerhetskopiering och återställning

Oracle erbjuder många säkerhetskopieringsmekanismer inklusive hot backup, backup, import, export och många andra.

I motsats till MySQL erbjuder MariaDB ett externt verktyg för heta säkerhetskopieringar som kallas mariabackup. Det är en gaffel av Percona XtraBackup designad för att fungera med krypterade och komprimerade tabeller och är den rekommenderade säkerhetskopieringsmetoden för MariaDB-databaser.

MariaDB Server 10.1 introducerade MariaDB Compression och Data-at-Rest Encryption, men de befintliga säkerhetskopieringslösningarna stödde inte full säkerhetskopieringskapacitet för dessa funktioner. Så MariaDB bestämde sig för att utöka XtraBackup (version 2.3.8) och döpte denna lösning till Mariabackup.

Percona och Mariabackup erbjuder liknande funktioner, men om du är intresserad av skillnader kan du hitta dem här.

Vad MariaDB inte erbjuder är återställningskatalogen för dina databassäkerhetskopior. Lyckligtvis kan detta utökas med tredjepartssystem som ClusterControl.

Molnkompatibilitet

Molninfrastrukturer blir allt populärare i dessa dagar. Även om en moln-VM kanske inte är lika pålitlig som en server i företagsklass, erbjuder de största molnleverantörerna en mängd olika verktyg för att öka tjänsternas tillgänglighet. Du kan välja mellan EC2-arkitektur eller DBaaS som Amazon RDS.

Amazon RDS stöder MariaDB Server 10.3. Det stöder inte SQL_MODE=Oracle men du kan fortfarande hitta en uppsättning funktioner som gör det lättare att migrera. Amazon moln stöder vanliga hanteringsuppgifter som övervakning, säkerhetskopiering, multi A-Z-distributioner, etc..

En annan populär molnleverantör, Google Cloud, erbjuder också den senaste MariaDB-versionen. Du kan distribuera den som en container- eller Bintami-bibliotekscertifierad VM-avbildning.

Azure erbjuder också sin egen implementering av MariaDB. Det liknar Amazon RDS, med säkerhetskopieringar, skalning och byggen i hög tillgänglighet. Den garanterade SLA:n är 99,99 % vilket motsvarar 4 m 23 sekunders driftstopp per månad.

Övriga överväganden

Som nämnts i början av den här artikeln är Oracle till MariaDB-migrering en process i flera steg. Ett allmänt råd är att inte försöka migrera alla databaser på en gång. Att dela upp migreringen i små partier är, i de flesta scenarier, den bästa metoden.

Om du inte är bekant med tekniken, prova det. Du bör känna dig trygg med plattformen och veta att den har för- och nackdelar. Testning kommer att bygga upp förtroende och det påverkar dina beslut när det gäller migrering.

Det finns intressanta verktyg som kan hjälpa dig med den svåraste PL/SQL-migreringsprocessen. Så intressanta är dbconvert, AWS Schema Conversion Tool - AWS Documentation.

Under åren har MariaDB fått Enterprise-stöd och mognad för att köra kritiska och komplexa datatransaktionssystem. Med den senaste versionen har MariaDB lagt till några fantastiska nya funktioner som SQL_Mode=Oracle-kompatibilitet, vilket gör övergångsprocessen enklare än någonsin tidigare.

Slutligen kan du gå med mig den 12 mars för ett webbseminarium där jag går igenom allt du behöver veta när det gäller att migrera från Oracle-databasen till MariaDB.