MySQL-migratie: prestaties en dataconsistentie controleren

Een geslaagde import is niet het eindcriterium

Een MySQL-migratie is pas bruikbaar wanneer de gegevens correct zijn, de applicatie werkt en de afgesproken prestaties haalbaar blijven. Dat een import zonder fout eindigt bewijst geen van die drie zaken volledig. Maak vooraf een inventaris van versies, storage engines, schema’s, indexen, collations, tekensets, SQL-modes, tijdzones, gebruikersrechten, triggers, routines en events. Neem ook externe jobs en applicatiekoppelingen mee. Benoem welke gegevens en processen buiten scope vallen en wie de migratie mag goedkeuren.

Bewijs dat herstel en snapshotgrenzen kloppen

Test het terugzetten van de backup op een afzonderlijke omgeving. Een aanwezig backupbestand bewijst niet dat de benodigde schema’s, routines en rechten correct herstellen. Een consistente vergelijking vereist een duidelijk snapshotmoment. Bij doorlopende writes kunnen twee correcte systemen verschillende aantallen tonen. Een mysqldump met --single-transaction is niet vanzelf een consistente backup voor niet-transactionele tabellen of gelijktijdige DDL. Kies de methode op basis van engines, volume en toegestane downtime; leg eventuele replicatieachterstand en het laatste verwerkte wijzigingspunt vast.

Controleer inhoud, niet alleen aantallen

Dit geïsoleerde voorbeeld maakt twee tijdelijke tabellen met dezelfde drie ID’s. Op de doelzijde heeft ID 2 opzettelijk een ander bedrag. COUNT(*) is gelijk, maar de inhoud klopt niet. Bedragen staan hier in gehele centen om een vergelijking met floats te vermijden. Voer het blok alleen uit in een nieuwe verbinding met een afzonderlijke MySQL-testdatabase en stop bij de eerste fout. Dit is een fixture, geen script dat je productie migreert. Sluit de sessie om de tijdelijke tabellen op te ruimen.

-- Synthetic data only. NEW session in a separate MySQL test database.
-- Never run in production. Stop at the first error; close the session afterwards.
CREATE TEMPORARY TABLE cg_migration_source (
    id INTEGER NOT NULL PRIMARY KEY, amount_cents INTEGER NULL
);
CREATE TEMPORARY TABLE cg_migration_target (
    id INTEGER NOT NULL PRIMARY KEY, amount_cents INTEGER NULL
);
INSERT INTO cg_migration_source VALUES (1,1000),(2,2500),(3,NULL);
INSERT INTO cg_migration_target VALUES (1,1000),(2,2501),(3,NULL);

SELECT 'source' AS dataset, COUNT(*) AS row_count FROM cg_migration_source
UNION ALL
SELECT 'target' AS dataset, COUNT(*) AS row_count FROM cg_migration_target;

-- Expected: one difference, id 2. NULL mismatches are tested explicitly.
SELECT s.id, s.amount_cents AS source_amount, t.amount_cents AS target_amount
FROM cg_migration_source s
LEFT JOIN cg_migration_target t ON t.id = s.id
WHERE t.id IS NULL
   OR s.amount_cents <> t.amount_cents
   OR (s.amount_cents IS NULL AND t.amount_cents IS NOT NULL)
   OR (s.amount_cents IS NOT NULL AND t.amount_cents IS NULL)
ORDER BY s.id;

-- Also check unexpected target IDs; a one-direction comparison is insufficient.
-- Expected: no rows for this fixture.
SELECT t.id FROM cg_migration_target t
LEFT JOIN cg_migration_source s ON s.id = t.id
WHERE s.id IS NULL
ORDER BY t.id;

Controleer in de echte migratie ontbrekende en extra sleutels in beide richtingen, NULL-waarden, bedragen, datums en relaties. Vergelijk binnen hetzelfde afgesproken snapshot. Een steekproef of een simpele checksum geeft andere zekerheid dan een volledige inhoudelijke vergelijking. Documenteer welke kolommen en records werkelijk zijn gecontroleerd en welke verschillen bewust verwacht zijn. Een foutloos resultaat van deze kleine fixture zegt niets over de volledigheid van een echte klantdatabase.

Vergelijk prestaties onder dezelfde voorwaarden

Kies vóór de proefmigratie enkele representatieve zoekopdrachten, rapporten en schrijfflows. Meet bron en doel met dezelfde data, parameters, cachecondities en belastingsprofielen. Bekijk naast responstijd ook foutaantallen, locks, queryplannen en resourcegebruik. Een snellere SELECT compenseert geen ontbrekende achtergrondjob of falende transactie. Herstel statistieken waar de gebruikte migratiemethode en databaseversie dat vereisen, en test de applicatie met dezelfde instellingen als voorzien voor de overgang.

Plan de cutover en terugval expliciet

Spreek stopcriteria, onderhoudsvenster, toegestane downtime, beslissingsbevoegdheid en controles na omschakeling af. Nadat het doel nieuwe writes accepteert, kan terugwijzen naar een oude bron recente wijzigingen verliezen. Een rollbackplan moet daarom ook die nieuwe gegevens behandelen, bijvoorbeeld via een vooraf getest reconciliatiepad of een gecontroleerde schrijfpauze. Beloof geen zero downtime zonder een bewezen ontwerp. Rond de migratie pas af wanneer data-, applicatie- en performancecontroles zijn vastgelegd en de verantwoordelijke akkoord geeft.

Verder onderzoeken

Een queryplan is één deel van de diagnose. Hieronder vind je aanvullende uitleg en een afgebakende SQL-dienst. De demonstraties gebruiken fictieve gegevens, niet de resultaten van een klantproject. Deel bij een aanvraag alleen een probleembeschrijving en geanonimiseerde context; geen wachtwoorden, volledige dumps of persoonsgegevens.

• Een trage MySQL-query onderzoeken met EXPLAIN
• Database-indexen kiezen op basis van echte Laravel-query’s
• SQL-queryoptimalisatie laten onderzoeken
• Reproduceerbare SQL-demonstratie
• Vraag een SQL-analyse aan