Een raming maken van een databasemigratie
Hoe een databasemigratie in te schatten: backfill, vergrendelingsduur, uitrol en terugdraaien. ‘Een kolom toevoegen’ is één regel SQL; de schatting betreft de tweede klok.
“Een kolom toevoegen” is een migratie van één regel. De schatting heeft geen betrekking op de kolom.
Bij schemamigraties spelen twee tijdsfactoren een rol. De ene is de SQL — doorgaans snel en meestal routinematig. De andere is de operationele klok: hoe lang wordt de tabel vergrendeld, wat gebeurt er bij gelijktijdige schrijfbewerkingen, hoe kunt u de bewerking ongedaan maken als er iets misgaat, en wat is het noodplan als de bewerking langer duurt dan het implementatievenster? Het team stemt over de SQL, omdat dat op het ticket staat. Het werk vindt plaats op de tweede klok.
Op een klein tafeltje zijn de twee klokken identiek en is het verhaal werkelijk onbeduidend. Op elke tafel die ertoe doet, is dat echter niet het geval. Bij de schatting moet rekening worden gehouden met de backfill, de implementatiestrategie en de rollback, die iemand moet hebben geoefend voordat de implementatie ook maar in de buurt van de productieomgeving komt.
Wat er in de kamer wordt gezegd
Backend: “Het is slechts een ALTER; de migratie is binnen een seconde voltooid.”
SRE: „Op de ordertabel? Met vergrendelde posities? Om 15.00 uur?“
DBA: “Hoe vullen we bestaande rijen aan?”
SRE: “Wat is de terugdraaiingsprocedure als de implementatie halverwege mislukt?”
Kernvraag: “Kan het leesproces het aan dat de kolom een uur lang de waarde ‘null’ heeft?”
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Hoe groot is de tabel — duizenden, miljoenen of honderden miljoenen rijen?
- Online migratietool of ALTER ter plaatse?
- Backfill-strategie: synchroon, batchverwerking, dubbele schrijfbewerking?
- Wat doet het leespad tijdens het implementatievenster?
- Rollback: alleen vooruit, of kunnen we het schema terugdraaien?
- Heeft iemand het draaiboek voor de oproepdienst bij deze migratie al doorgenomen?
Als de helft van de aanwezigen voor „de SQL“ stemt en de andere helft voor „de uitrol“, dan hebt u geen probleem met het aantal; u hebt te maken met twee verhalen die doen alsof ze één zijn. Splits het op: de schemawijziging is één onderdeel, het plan voor het bijwerken van de gegevens en de uitrol is een ander onderdeel.
Maak een schatting van de implementatie en de terugdraaiing, niet van de ALTER-opdracht. Het risico schuilt in de tweede fase.
Zie het maken van een schatting voor een gegevensmigratie voor de systeemoverschrijdende variant, en de andere praktijkvoorbeelden van schattingen. Start een gratis planning poker-sessie zodra de uitrol in grote lijnen is geschetst.