Migrering fra MySQL til PostgreSQL - hvad du bør vide

Uanset om du migrerer en database eller et projekt fra MySQL til PostgreSQL eller vælger PostgreSQL til et nyt projekt med kun MySQL viden, er der et par ting at vide om PostgreSQL og forskellene mellem de to databasesystemer.

PostgreSQL er et fuldt open source-databasesystem udgivet under sin egen licens, PostgreSQL-licensen, som beskrives som "en liberal Open Source-licens, der ligner BSD- eller MIT-licenserne." Dette har gjort det muligt for PostgreSQL Global Development Group (almindeligvis omtalt som PGDG), som udvikler og vedligeholder open source-projektet, at forbedre projektet med hjælp fra mennesker rundt om i verden, hvilket gør det til en af ​​de mest stabile og funktionsrige databaseløsninger tilgængelig. I dag konkurrerer PostgreSQL med de bedste proprietære og open source-databasesystemer for funktioner, ydeevne og popularitet.

PostgreSQL er et yderst kompatibelt relationelt databasesystem, der kan skaleres, tilpasses og har et blomstrende fællesskab af mennesker, der forbedrer det hver dag.

Hvad PostgreSQL har brug for

I en tidligere blog diskuterede vi opsætning og optimering af PostgreSQL til et nyt projekt. Det er en god introduktion til PostgreSQL-konfiguration og adfærd, og kan findes her:https://severalnines.com/blog/setting-optimal-environment-postgresql.

Hvis du migrerer en applikation fra MySQL til PostgreSQL, ville det bedste sted at starte være at hoste den på lignende hardware eller hostingplatform som MySQL-kildedatabasen.

On Premise

Hvis du hoster databasen på stedet, er bare metal-værter (i stedet for virtuelle maskiner) generelt den bedste mulighed for at hoste PostgreSQL. Virtuelle maskiner tilføjer nogle gange nogle nyttige funktioner, men de kommer på bekostning af at miste kraft og ydeevne fra værten generelt, mens bare metal tillader PostgreSQL-softwaren at have fuld adgang til ydeevne med færre lag mellem den og hardwaren. On-premise værter ville have brug for en administrator til at vedligeholde databaserne, uanset om det er en fuldtidsansat eller entreprenør, alt efter hvad der giver mest mening for applikationens behov.

I skyen

Cloud-hosting er kommet langt i de sidste par år, og utallige virksomheder over hele verden hoster deres databaser på cloud-baserede servere. Da cloud-værter er meget konfigurerbare, kan den rigtige størrelse og kraft af værten vælges til databasens specifikke behov med en pris, der matcher.

Afhængigt af den anvendte hostingmulighed kan nye værter hurtigt klargøres, hukommelse / cpu / disk kan justeres hurtigt, og endda yderligere backupmetoder kan være tilgængelige. Når du vælger en cloud-vært, skal du kigge efter, om en vært er dedikeret eller delt, da dedikeret er bedre til databaser med ekstremt høj belastning. En anden nøgle er at sikre, at den tilgængelige IOPS for cloud-værten er god nok til databaseaktivitetsbehovene. Selv med en stor hukommelsespulje til PostgreSQL, vil der altid være diskoperationer til at skrive data til disk eller hente data, når de ikke er i hukommelsen.

Cloud-tjenester

Da PostgreSQL er stigende i popularitet, bliver det fundet tilgængeligt på mange cloud-database-hostingtjenester som Heroku, Amazon AWS og andre og er hurtigt ved at indhente MySQL's popularitet. Disse tjenester giver en tredjepart mulighed for nemt at hoste og administrere en PostgreSQL-database, så fokus forbliver på applikationen.

Koncepter / term sammenligninger

Der er et par sammenligninger, der skal dækkes ved migrering fra MySQL til PostgreSQL, almindelige konfigurationsparametre, termer eller koncepter, der fungerer på samme måde, men som har deres forskelle.

Databasevilkår

Forskellige databaseudtryk kan have forskellige betydninger inden for forskellige implementeringer af teknologien. Mellem MySQL og PostgreSQL er der nogle få grundlæggende udtryk, der forstås lidt anderledes, så en oversættelse er nogle gange nødvendig.

"Klynge"

I MySQL refererer en 'klynge' normalt til flere MySQL-databaseværter, der er forbundet sammen for at fremstå som en enkelt database eller et sæt databaser til klienter.

I PostgreSQL, når der refereres til en 'klynge', er det en enkelt kørende forekomst af databasesoftwaren og alle dens underprocesser, som så indeholder en eller flere databaser.

“Database”

I MySQL kan forespørgsler få adgang til tabeller fra forskellige databaser på samme tid (forudsat at brugeren har tilladelse til at få adgang til hver database).

SELECT *
FROM customer_database.customer_table t1
JOIN orders_database.order_table t2 ON t1.customer_id = t2.customer_id
WHERE name = ‘Bob’;

Men i PostgreSQL kan dette ikke ske, medmindre du bruger Foreign Data Wrappers (et emne til en anden gang). I stedet har en PostgreSQL-database mulighed for flere 'skemaer', som fungerer på samme måde som databaser i MySQL. Skemaer indeholder tabeller, indekser osv., og kan tilgås samtidigt via den samme forbindelse til databasen, som huser dem.

SELECT *
FROM customer_schema.customer_table t1
JOIN orders_schema.order_table t2 ON t1.customer_id = t2.customer_id
WHERE name = ‘Bob’;

Interface med PostgreSQL

I MySQL-kommandolinjeklienten (mysql), bruger grænsefladen til databasen nøgleværker som 'DESCRIBE table' eller 'SHOW TABLES'. PostgreSQL-kommandolinjeklienten (psql) bruger sin egen form for 'backslash-kommandoer'. For eksempel, i stedet for 'SHOW TABLES', er PostgreSQL's kommando '\dt', og i stedet for 'SHOW DATABASES;' er kommandoen '\l'.

En komplet liste over kommandoer til 'psql' kan findes ved omvendt skråstreg kommandoen '\?' i psql.

Sprogsupport

Ligesom MySQL har PostgreSQL biblioteker og plugins til alle større sprog, såvel som ODBC-drivere på linje med MySQL og Oracle. At finde et fantastisk og stabilt bibliotek til ethvert behov for sprog er en nem opgave.

Lagrede procedurer

I modsætning til MySQL har PostgreSQL en bred vifte af understøttede proceduresprog at vælge imellem. I basisinstallationen af ​​PostgreSQL er de understøttede sprog PL/pgSQL (SQL Procedural Language), PL/Tcl (Tcl Procedural Language), PL/Perl (Perl Procedural Language) og PL/Python (Python Procedural Language). Tredjepartsudviklere har muligvis flere sprog, der ikke officielt understøttes af PostgreSQL-hovedgruppen.

Konfiguration

• Hukommelse

  MySQL justerer dette med key_buffer_size, når du bruger MyISAM, og med innodb_buffer_pool_size, når du bruger InnoDB.

  PostgreSQL bruger shared_buffers til den primære hukommelsesblok, der er givet til databasen til cachelagring af data, og holder sig generelt omkring 1/4 af systemhukommelsen, medmindre visse scenarier kræver, at det ændres. Forespørgsler, der bruger hukommelse til sortering, bruger værdien work_mem, som bør øges forsigtigt.

Værktøjer til migrering

Migrering til PostgreSQL kan tage noget arbejde, men der er værktøjer, som fællesskabet har udviklet til at hjælpe med processen. Generelt vil de konvertere / migrere data fra MySQL til PostgreSQL og genskabe tabeller / indekser. Lagrede procedurer eller funktioner er en anden historie og kræver normalt manuel omskrivning enten delvist eller fra bunden.

Nogle tilgængelige eksempler på værktøjer er pgloader og FromMySqlToPostgreSql. Pgloader er et værktøj skrevet i Common Lisp, der importerer data fra MySQL til PostgreSQL ved hjælp af COPY-kommandoen, og indlæser data, indekser, fremmednøgler og kommentarer med datakonvertering for at repræsentere dataene korrekt i PostgreSQL efter hensigten. FromMySqlToPostgreSql er et lignende værktøj skrevet i PHP, og kan konvertere MySQL datatyper til PostgreSQL samt fremmednøgler og indekser. Begge værktøjer er gratis, men mange andre værktøjer (gratis og betalte) findes og er nyudviklede, efterhånden som nye versioner af hver databasesoftware frigives.

Konvertering bør altid omfatte en dybdegående evaluering efter migreringen for at sikre, at data blev konverteret korrekt, og at funktionaliteten fungerer som forventet. Testning på forhånd er altid tilskyndet til timings og datavalidering.

Replikeringsmuligheder

Hvis det kommer fra MySQL, hvor replikering er blevet brugt, eller der overhovedet er behov for replikering af en eller anden grund, har PostgreSQL flere muligheder, hver med sine egne fordele og ulemper, afhængigt af hvad der er behov for gennem replikering.

• Indbygget:

  Som standard har PostgreSQL sin egen indbyggede replikeringstilstand til Point In Time Recovery (PITR). Dette kan sættes op ved hjælp af enten filbaseret logforsendelse, hvor Write Ahead Log-filer sendes til en standby-server, hvor de læses og afspilles igen, eller Streaming Replication, hvor en skrivebeskyttet standby-server henter transaktionslogfiler over en databaseforbindelse for at afspille dem igen. dem.

  En af disse indbyggede muligheder kan konfigureres som enten en "varm standby" eller "hot standby." En "varm standby" tillader ikke forbindelser, men er klar til at blive en master til enhver tid for at erstatte en master, der har problemer . En 'hot standby' giver skrivebeskyttede forbindelser mulighed for at oprette forbindelse og udstede forespørgsler, ud over at være klar til at blive læse-/skrivemester til enhver tid, hvis det er nødvendigt.

• Slony:

  Et af de ældste replikeringsværktøjer til PostgreSQL er Slony, som er en triggerbaseret replikeringsmetode, der tillader et højt niveau af tilpasning. Slony tillader opsætning af en Master node og et hvilket som helst antal Replica noder, og muligheden for at skifte Master til en hvilken som helst node, og giver administratoren mulighed for at vælge hvilke tabeller (hvis ikke alle tabeller vil) der skal replikeres. Det er ikke kun blevet brugt til at replikere data i tilfælde af fejl/belastningsbalancering, men til at sende specifikke data til andre tjenester eller endda minimale nedetidsopgraderinger, da replikering kan gå på tværs af forskellige versioner af PostgreSQL.

  Slony har det vigtigste krav, at hver tabel, der skal replikeres, enten har en PRIMÆR NØGLE eller et UNIKT indeks uden nullbare kolonner.

• Bucardo:

  Når det kommer til multi-master muligheder, er Bucardo en af ​​få til PostgreSQL. Ligesom Slony er det en tredjeparts softwarepakke, der sidder oven på PostgreSQL. Bucardo kalder sig selv "et asynkront PostgreSQL-replikeringssystem, der giver mulighed for både multi-master og multi-slave operationer." Den største fordel er multi-master replikering, som fungerer ret godt, men den mangler konfliktløsning, så applikationer bør være opmærksomme på mulige problemer og rette i overensstemmelse hermed.

  Der er også mange andre replikeringsværktøjer, og at finde det, der fungerer bedst til en applikation, afhænger af de specifikke behov.

Fællesskab

PostgreSQL har et blomstrende fællesskab, der er villig til at hjælpe med eventuelle problemer/oplysninger, der måtte være nødvendige.

• IRC

  Et aktivt IRC-chatroom ved navn #postgresql er tilgængeligt på freenode, da administratorer og udviklere chatter over hele verden om PostgreSQL og relaterede projekter/problemer. Der er endnu mindre lokaler til detaljer som Slony, Bucardo og mere.

• Postlister

  Der er en håndfuld PostgreSQL-mailinglister for 'generelt', 'admin', 'performance' og endda 'novice' (et godt sted at starte, hvis du er ny i PostgreSQL generelt). Mailinglisterne abonnerer på af mange rundt om i verden og giver et meget nyttigt væld af ressourcer til at besvare ethvert spørgsmål, der måske skal besvares.

  En komplet liste over PostgreSQL-mailinglister kan findes på https://www.postgresql.org/list/

• Brugergrupper

  Brugergrupper er et fantastisk sted at blive involveret og aktivt i fællesskabet, og mange store byer verden over har en PostgreSQL User Group (PUG) tilgængelig for at deltage og deltage i, og hvis ikke, så overvej at starte en. Disse grupper er fantastiske til at netværke, lære nye teknologier og endda bare stille spørgsmål personligt til folk uanset erfaringsniveau.

• Dokumentation

  Det vigtigste er, at PostgreSQL er dokumenteret meget godt. Enhver information om konfigurationsparametre, SQL-funktioner, brug, alt sammen kan nemt læres gennem den officielle dokumentation på PostgreSQLs hjemmeside. Hvis noget overhovedet er uklart, vil fællesskabet hjælpe med de tidligere skitserede muligheder.