MySQL-zu-Postgres-Migration — wann es sich lohnt, die Stolperfallen und der pgloader-Workflow

Wir haben Datenbanken in beide Richtungen migriert: MySQL → Postgres für Teams, die reiche Indexe, echte ACID-Semantiken auf DDL und die JSONB-Story brauchen; Postgres → MySQL für Teams, die das Postgres-Connection-Modell für ihre Workload zu teuer fanden. Die Migration ist in beide Richtungen ein echtes Stück Engineering, und die falschen Gründe es zu tun („wir mögen es lieber") werden Monate verbrennen.

Hier sind der Entscheidungsrahmen, die Datentyp-Fallen und der pgloader-Workflow, den wir nutzen, wenn MySQL → Postgres der richtige Ruf ist.

Der pgloader-Einstiegspunkt

LOAD DATABASE
  FROM mysql://user:pass@source/dbname
  INTO postgresql://user:pass@dest/dbname
 
WITH include drop, create tables, create indexes, reset sequences,
     workers = 8, concurrency = 1,
     multiple readers per thread, rows per range = 50000
 
CAST type datetime to timestamptz drop default drop not null using zero-dates-to-null,
     type tinyint when (= precision 1) to boolean using tinyint-to-boolean
;

pgloader bewältigt 80 % der Typ-Übersetzung automatisch. Die verbleibenden 20 % sind, wo das Engineering passiert.

Der vollständige Beitrag behandelt:

• Wann Migration die richtige Antwort ist (und die drei häufigen schlechten Gründe)
• Die Datentyp-Fallen: Zero Dates, tinyint(1) vs Boolean, BLOB vs bytea, Zeichensatz-Handhabung
• Sequence-Reset nach dem Daten-Load
• Anwendungsseitige Änderungen (Case-Sensitivity, LIMIT/OFFSET-Performance, RETURNING statt SELECT LAST_INSERT_ID)
• Das Dual-Write-Cutover-Pattern für Live-Datenbanken
• Row-Counts und Checksums zwischen Quelle und Ziel verifizieren

Melden Sie sich, wenn Sie diese Migration für eine echte Workload abwägen.