Een raming maken van een databasemigratie
Hoe u een databasemigratie kunt inschatten: backfill, vergrendelingsduur, uitrol en terugdraaiing. ‘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 het proces ongedaan maken als er iets misgaat, en wat is het noodplan als het 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 raming 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 vergrendelingen ingeschakeld? Om 15.00 uur?”
DBA: “Hoe vullen wij bestaande rijen aan?”
SRE: “Wat is de terugdraaiingsprocedure als de implementatie halverwege mislukt?”
Leidende vraag: “Kan het leespad het aan dat de kolom een uur lang de waarde ‘null’ heeft?”
Vragen die het waard zijn om te 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 wij het schema terugdraaien?
- Heeft iemand het draaiboek voor de oproepdienst bij deze migratie gevolgd?
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 twee verhalen die doen alsof ze één zijn. Splits het op: de schemawijziging is één ticket, het backfill- en uitrolplan is een ander.
Maak een schatting van de implementatie en de terugdraaiing, niet van de ALTER-opdracht. Het risico schuilt in de tweede fase.
Zie „Een schatting maken van een gegevensmigratie” voor de systeemoverschrijdende variant, evenals de andere uitgewerkte schattingsvoorbeelden. Start een gratis planning poker-sessie zodra de uitrol in grote lijnen is geschetst.