Waarom voert een zelfgehoste app na een nieuwe implementatie dezelfde databasemigratie twee keer uit?

Een databasemigratie kan twee keer worden uitgevoerd wanneer meer dan één opstartpad, container of scheduler denkt dat deze verantwoordelijk is voor dezelfde upgradestap.

Zelfgehoste applicaties starten migraties vaak vanuit een entrypoint, webproces, worker, sidecar, systemd-eenheid of implementatiehook. Na een nieuwe implementatie kan een oude container overlappen met een nieuwe, kan een herstartbeleid een mislukte migrator opnieuw starten of kunnen twee replica's de database bereiken voordat een ervan de voltooiing registreert. De diagnose moet elke mogelijke uitvoerder identificeren en aantonen of het migratieframework een duurzame vergrendeling of een schemaregistratie gebruikt voordat gegevens worden hersteld.

Identificeer elk proces dat de migratie kan starten

Zoek in het image-entrypoint, de Compose-opdracht, de worker-opdracht, de systemd-eenheid, cronjob, het implementatiescript en het opstartlogboek van de applicatie naar de migratieopdracht. Noteer proces-ID's en containernamen op de twee uitvoeringstijdstippen.

Docker Compose kan services starten op basis van opgegeven afhankelijkheden, maar alleen de opstartvolgorde maakt een migratie op applicatieniveau niet uniek eigendom. De officiële richtlijnen voor de opstartvolgorde laten zien waarom een beschikbare database en uniek eigendom van een migratie afzonderlijke voorwaarden zijn.

Als dezelfde opdracht zowel in het web-entrypoint als in een speciale migratieservice voorkomt, verwijder dan één eigenaar. Als er maar één opdracht bestaat, ga dan verder met het controleren van replica's, herstartlussen en migratiestatusregistraties.

Controleer op overlappende oude en nieuwe containers

Maak tijdens de implementatie een lijst van actieve, herstartende, gestopte en verweesde containers. Vergelijk projectnamen, servicenamen, container-ID's en aanmaaktijdstippen.

Systemd documenteert dat het herstartbeleid van een service een mislukte opdracht opnieuw kan starten volgens de instellingen van de eenheid. Het herstartmodel van de service helpt verklaren waarom een hoststarter de migratie opnieuw kan uitvoeren nadat de containerpoging met een foutcode is beëindigd.

Verwijder aantoonbaar verweesde uitvoerders pas nadat je hun logboeken hebt bewaard. Een tweede migratietijdstip kort na het eerste wijst vaak op een nieuwe poging en niet op een afzonderlijk geplande taak.

Gebruik een databasevergrendeling voordat je schemaveranderingen toepast

Bepaal of de applicatie een vergrendeling op databaseniveau verkrijgt voordat de migratiestatus wordt gelezen en wijzigingen worden toegepast. Test twee gelijktijdige opstartpogingen in een wegwerpomgeving.

PostgreSQL biedt advisorylocks voor coördinatie die door applicaties wordt gedefinieerd, waarmee één migratie-uitvoerder een andere kan uitsluiten, zelfs wanneer beide vrijwel gelijktijdig starten.

Een vergrendeling moet het volledige beslissings- en uitvoeringsvenster omvatten. Als je de huidige schemaversie controleert voordat je de vergrendeling verkrijgt, kunnen twee uitvoerders nog steeds dezelfde openstaande migratie selecteren.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer de vergrendelingssemantiek voor MySQL of MariaDB

Controleer bij MySQL-compatibele applicaties of de migratietool een benoemde vergrendeling, transactie of vergrendelingstabel gebruikt en of de verbinding gedurende de volledige migratie actief blijft.

MySQL documenteert verbindingsgebonden benoemde vergrendelingen. Deze worden vrijgegeven wanneer de sessie die eigenaar is wordt beëindigd en moeten daarom na een crash of herstart veilig opnieuw worden verkregen.

Een verbroken verbinding kan de vergrendeling vrijgeven voordat het migratieframework de voltooiing registreert. Vergelijk databaselogboeken met tijdstippen van containerherstarts om deze volgorde vast te stellen.

Inspecteer de geschiedenistabel van het migratieframework

Maak een lijst van migratie-ID's, uitvoeringsvolgorde, succesvlaggen, checksums en tijdstempels. Vergelijk de twee gelogde uitvoeringen met de records die daadwerkelijk in de database zijn vastgelegd.

Flyway gebruikt een schemageschiedenistabel om toegepaste migraties en hun statussen bij te houden.

Als de eerste uitvoering het schema heeft gewijzigd maar is mislukt voordat het succes werd geregistreerd, kan de tweede uitvoering een migratie opnieuw proberen die niet idempotent is geschreven. Herstel de geschiedenis pas nadat je het werkelijke schema hebt vergeleken met het verwachte resultaat van de migratie.

Controleer de identiteit van de changelog en wijzigingen in checksums

Vergelijk migratiebestandsnamen, ID's, auteurs, paden en checksums voor en na de image-update. Bepaal of het image dubbele of hernoemde changelogitems bevat.

Liquibase registreert uitgevoerde wijzigingen in de DATABASECHANGELOG-tabel, waarbij de identiteit van een wijziging afhankelijk is van het ID, de auteur en het bestandspad.

Door een changelogbestand te verplaatsen of ID's opnieuw te genereren, kan eerder werk als nieuw worden gezien, zelfs wanneer de SQL vergelijkbaar is. Herstel een stabiele migratie-identiteit in plaats van brede geschiedenisreeksen handmatig te verwijderen.

Implementeer opnieuw met één migratie-eigenaar en controleer idempotentie

Kies één migratie-eigenaar, voeg duurzame vergrendeling toe, laat de web- en workerservices wachten op een succesvolle voltooiing en implementeer opnieuw in een testkopie van de database.

Het ZimaSpace-artikel over planningsgrenzen van containers biedt de bijbehorende regel: één onderhoudstaak hoort één aantoonbare runtime-eigenaar te hebben.

Het probleem is opgelost wanneer gelijktijdige of herhaalde starts één toegepaste migratie, één duurzame geschiedenisinvoer en geen tweede schemamutatie na een herstart opleveren.

Veelgestelde vragen

Beschadigt het twee keer uitvoeren van een migratie de database altijd?

Nee. Idempotente migraties kunnen bestaande objecten veilig detecteren, maar niet-idempotente datatransformaties, het aanmaken van indexen of kolomwijzigingen kunnen mislukken of gegevens dupliceren.

Mogen alle webreplica's migraties uitvoeren?

Alleen wanneer het framework betrouwbare coördinatie op databaseniveau biedt. Een speciale migratie-eigenaar die slechts één keer wordt uitgevoerd, is gemakkelijker te controleren in een thuisserverimplementatie.

Kan ik de migratie handmatig als voltooid markeren?

Alleen nadat je hebt aangetoond dat het actieve schema en de gegevens overeenkomen met het verwachte resultaat van de migratie. Als je de geschiedenis eerst bewerkt, kan dat een gedeeltelijk toegepaste wijziging verbergen.