Migrera från MySQL till PostgreSQL - Vad du bör veta

Oavsett om du migrerar en databas eller ett projekt från MySQL till PostgreSQL, eller väljer PostgreSQL för ett nytt projekt med enbart MySQL-kunskap, finns det några saker att veta om PostgreSQL och skillnaderna mellan de två databassystemen.

PostgreSQL är ett helt öppen källkodsdatabassystem släppt under sin egen licens, PostgreSQL-licensen, som beskrivs som "en liberal öppen källkodslicens, liknande BSD- eller MIT-licenserna." Detta har gjort det möjligt för The PostgreSQL Global Development Group (vanligtvis kallad PGDG), som utvecklar och underhåller open source-projektet, att förbättra projektet med hjälp av människor runt om i världen och förvandla det till en av de mest stabila och funktionsrika databaslösningarna tillgänglig. Idag konkurrerar PostgreSQL med de främsta patentskyddade och öppen källkodsdatabassystemen för funktioner, prestanda och popularitet.

PostgreSQL är ett mycket kompatibelt relationsdatabassystem som är skalbart, anpassningsbart och har en blomstrande gemenskap av människor som förbättrar det varje dag.

Vad PostgreSQL behöver

I en tidigare blogg diskuterade vi att sätta upp och optimera PostgreSQL för ett nytt projekt. Det är en bra introduktion till PostgreSQL-konfiguration och beteende, och kan hittas här:https://severalnines.com/blog/setting-optimal-environment-postgresql.

Om du migrerar en applikation från MySQL till PostgreSQL skulle det bästa stället att börja vara att vara värd för den på liknande hårdvara eller värdplattform som MySQL-källdatabasen.

På plats

Om du är värd för databasen på plats är värdar av ren metall (snarare än virtuella maskiner) i allmänhet det bästa alternativet för att vara värd för PostgreSQL. Virtuella maskiner lägger till några användbara funktioner ibland, men de kommer till priset av att förlora kraft och prestanda från värden i allmänhet, medan bar metal tillåter PostgreSQL-programvaran att ha full tillgång till prestanda med färre lager mellan den och hårdvaran. Lokala värdar skulle behöva en administratör för att underhålla databaserna, oavsett om det är en heltidsanställd eller entreprenör, beroende på vilket som är mer meningsfullt för applikationens behov.

I molnet

Molnvärd har kommit långt under de senaste åren, och otaliga företag över hela världen hostar sina databaser i molnbaserade servrar. Eftersom molnvärdar är mycket konfigurerbara kan rätt storlek och kraft på värden väljas för databasens specifika behov, med en kostnad som matchar.

Beroende på vilket värdalternativ som används kan nya värdar tillhandahållas snabbt, minne / cpu / disk kan justeras snabbt och till och med ytterligare säkerhetskopieringsmetoder kan vara tillgängliga. När du väljer en molnvärd, leta efter om en värd är dedikerad eller delad, dedikerad är bättre för databaser med extremt hög belastning. En annan nyckel är att se till att IOPS som är tillgänglig för molnvärden är tillräckligt bra för databasaktivitetsbehoven. Även med en stor minnespool för PostgreSQL kommer det alltid att finnas diskoperationer för att skriva data till disken eller hämta data när de inte finns i minnet.

Cloudtjänster

Eftersom PostgreSQL ökar i popularitet, finns det tillgängligt på många molndatabasvärdtjänster som Heroku, Amazon AWS och andra, och kommer snabbt ikapp MySQL:s popularitet. Dessa tjänster gör det möjligt för en tredje part att enkelt vara värd för och hantera en PostgreSQL-databas, vilket gör att fokus kan förbli på applikationen.

Koncept/termjämförelser

Det finns några jämförelser att täcka när man migrerar från MySQL till PostgreSQL, vanliga konfigurationsparametrar, termer eller koncept som fungerar på liknande sätt men som har sina skillnader.

Databasvillkor

Olika databastermer kan ha olika betydelser inom olika implementeringar av tekniken. Mellan MySQL och PostgreSQL finns det några grundläggande termer som förstås lite olika, så ibland behövs en översättning.

”Kluster”

I MySQL hänvisar ett "kluster" vanligtvis till flera MySQL-databasvärdar som är sammankopplade för att visas som en enda databas eller uppsättning databaser för klienter.

I PostgreSQL, när man refererar till ett "kluster", är det en enda körande instans av databasprogramvaran och alla dess underprocesser, som sedan innehåller en eller flera databaser.

”Databas”

I MySQL kan frågor komma åt tabeller från olika databaser samtidigt (förutsatt att användaren har behörighet att komma åt varje databas).

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 detta inte hända om man inte använder Foreign Data Wrappers (ett ämne för en annan gång). Istället har en PostgreSQL-databas möjlighet till flera "scheman" som fungerar på samma sätt som databaser i MySQL. Scheman innehåller tabeller, index, etc, och kan nås samtidigt genom samma anslutning till databasen som innehåller dem.

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

Gränssnitt med PostgreSQL

I MySQL-kommandoradsklienten (mysql), använder gränssnittet med databasen nyckelverk som "BESKRIV tabell" eller "VISA TABELLER". PostgreSQL kommandoradsklient (psql) använder sin egen form av "omvänt snedstreck kommandon". Till exempel, istället för 'SHOW TABLES', är PostgreSQL:s kommando '\dt', och istället för 'SHOW DATABASES;' är kommandot '\l'.

En fullständig lista med kommandon för 'psql' kan hittas av kommandot omvänt snedstreck '\?' i psql.

Språkstöd

Liksom MySQL har PostgreSQL bibliotek och plugins för alla större språk, såväl som ODBC-drivrutiner i linje med MySQL och Oracle. Att hitta ett bra och stabilt bibliotek för alla språk som behövs är en enkel uppgift.

Lagrade procedurer

Till skillnad från MySQL har PostgreSQL ett brett utbud av procedurspråk som stöds att välja mellan. I basinstallationen av PostgreSQL är de språk som stöds PL/pgSQL (SQL Procedural Language), PL/Tcl (Tcl Procedural Language), PL/Perl (Perl Procedural Language) och PL/Python (Python Procedural Language). Tredjepartsutvecklare kan ha fler språk som inte officiellt stöds av PostgreSQL-huvudgruppen.

Konfiguration

• Minne

  MySQL ställer in detta med key_buffer_size när du använder MyISAM och med innodb_buffer_pool_size när du använder InnoDB.

  PostgreSQL använder shared_buffers för huvudminnesblocket som ges till databasen för cachelagring av data, och håller sig vanligtvis runt 1/4 av systemminnet om inte vissa scenarier kräver att det ändras. Frågor som använder minne för sortering använder värdet work_mem, som bör ökas försiktigt.

Verktyg för migrering

Att migrera till PostgreSQL kan ta lite arbete, men det finns verktyg som communityn har utvecklat för att hjälpa till med processen. I allmänhet kommer de att konvertera / migrera data från MySQL till PostgreSQL och återskapa tabeller / index. Lagrade procedurer eller funktioner är en annan historia och kräver vanligtvis manuell omskrivning antingen delvis eller från grunden.

Några exempel tillgängliga är pgloader och FromMySqlToPostgreSql. Pgloader är ett verktyg skrivet i Common Lisp som importerar data från MySQL till PostgreSQL med kommandot COPY, och laddar data, index, främmande nycklar och kommentarer med datakonvertering för att representera data korrekt i PostgreSQL som avsett. FromMySqlToPostgreSql är ett liknande verktyg skrivet i PHP, och kan konvertera MySQL-datatyper till PostgreSQL såväl som främmande nycklar och index. Båda verktygen är gratis, men många andra verktyg (gratis och betalda) finns och är nyutvecklade när nya versioner av varje databasprogramvara släpps.

Konvertering bör alltid inkludera en djupgående utvärdering efter migreringen för att säkerställa att data har konverterats korrekt och att funktionaliteten fungerar som förväntat. Testning i förväg uppmuntras alltid för timings och datavalidering.

Replikeringsalternativ

Om det kommer från MySQL där replikering har använts, eller om replikering behövs överhuvudtaget av någon anledning, har PostgreSQL flera tillgängliga alternativ, alla med sina egna för- och nackdelar, beroende på vad som behövs genom replikering.

• Inbyggd:

  Som standard har PostgreSQL sitt eget inbyggda replikeringsläge för Point In Time Recovery (PITR). Detta kan ställas in med antingen filbaserad loggsändning, där Write Ahead Log-filer skickas till en standby-server där de läses och spelas upp igen, eller Streaming Replication, där en skrivskyddad standby-server hämtar transaktionsloggar över en databasanslutning för att spela upp dem igen dem.

  Endera av dessa inbyggda alternativ kan ställas in som antingen en "varm standby" eller "hot standby." En "varm standby" tillåter inte anslutningar men är redo att bli en master när som helst för att ersätta en master som har problem . Ett "hot standby" tillåter skrivskyddade anslutningar att ansluta och utfärda frågor, förutom att vara redo att bli en läs-/skrivmästare när som helst om det behövs.

• Slony:

  Ett av de äldsta replikeringsverktygen för PostgreSQL är Slony, som är en triggerbaserad replikeringsmetod som tillåter en hög nivå av anpassning. Slony tillåter inställningen av en masternod och valfritt antal replikanoder, och möjligheten att byta mastern till vilken nod som helst, och låter administratören välja vilka tabeller (om man inte vill ha alla tabeller) som ska replikeras. Det har använts inte bara för att replikera data i händelse av fel/lastbalansering, utan för att skicka specifik data till andra tjänster, eller till och med minimala driftstoppsuppgraderingar, eftersom replikering kan gå över olika versioner av PostgreSQL.

  Slony har det huvudsakliga kravet att varje tabell som ska replikeras har antingen en PRIMÄRNYCKEL eller ett UNIKT index utan nollbara kolumner.

• Bucardo:

  När det gäller multi-master-alternativ är Bucardo en av få för PostgreSQL. Liksom Slony är det ett tredjepartsmjukvarupaket som sitter ovanpå PostgreSQL. Bucardo kallar sig "ett asynkront PostgreSQL-replikeringssystem som tillåter både multi-master och multi-slave operationer." Den största fördelen är multi-master replikering, som fungerar ganska bra, men den saknar konfliktlösning, så applikationer bör vara medvetna om möjliga problem och fixa därefter.

  Det finns många andra replikeringsverktyg också, och att hitta det som fungerar bäst för en applikation beror på de specifika behoven.

Community

PostgreSQL har en blomstrande community som är villig att hjälpa till med alla problem/information som kan behövas.

• IRC

  Ett aktivt IRC-chattrum med namnet #postgresql är tillgängligt på freenode, som administratörer och utvecklare över hela världen chattar om PostgreSQL och relaterade projekt/frågor. Det finns ännu mindre rum för detaljer som Slony, Bucardo och mer.

• E-postlistor

  Det finns en handfull PostgreSQL-e-postlistor för "allmänt", "admin", "prestanda" och till och med "nybörjare" (ett bra ställe att börja om du är ny på PostgreSQL i allmänhet). E-postlistorna prenumereras på av många runt om i världen och ger en mycket användbar mängd resurser för att svara på alla frågor som kan behöva besvaras.

  En fullständig lista över PostgreSQL-postlistor finns på https://www.postgresql.org/list/

• Användargrupper

  Användargrupper är ett bra ställe att engagera sig och vara aktiv i samhället, och många stora städer över hela världen har en PostgreSQL User Group (PUG) tillgänglig att gå med och delta i, och om inte, överväg att starta en. Dessa grupper är utmärkta för att nätverka, lära sig ny teknik och till och med bara ställa frågor personligen till människor från alla nivåer av erfarenhet.

• Dokumentation

  Det viktigaste är att PostgreSQL är mycket väl dokumenterat. All information om konfigurationsparametrar, SQL-funktioner, användning, allt kan lätt läras genom den officiella dokumentationen som finns på PostgreSQL:s webbplats. Om något alls är oklart, kommer communityn att hjälpa till med de tidigare beskrivna alternativen.