Se o voso proxecto de software ten éxito, non pensedes que habedes ter un trono eterno no que vos escarranchar para sempre mentres un coro grego canta louvanzas e odas ás vosas vitorias. Non: a gloria da vitoria é efémera, e a recompensa por facer un bo traballo é máis traballo.
Fixestes o voso proxecto, lanzástelo, chegaron moitos usuarios e un día descubrides que o voso sistema non escala e tedes que substituír a base de datos. Por suposto, non vale con tirar ao lixo os datos vellos, iniciar unha base de datos nova e comezar a usala; queredes que todos os datos sigan dispoñibles trala mudanza.
Semella que ides ter que facer unha migración.
Todas as migracións que transcorren con éxito son iguais, pero cada migración frustrada fracasa na súa propia maneira. Polo tanto, temos que estudar as características dunha boa migración, que está ben planificada, é reversible, é gradual e non interrompe o servizo.
É imprescindible planificar ben a migración. Todos os pasos a realizar teñen que estar determinados de antemán e, idealmente, deberían ter detalle dabondo para que calquera empregado de sistemas poida executar a migración seguindo a documentación. Se non tedes un plan, non ides saber canto tempo vai tomar, ides ter que improvisar, e a migración vai producir moito estrés.
Sempre hai problemas nas migracións, así que o plan non debe incluír só os pasos a seguir se todo vai ben (o “happy path”), senón que tamén ten que ter instrucións para cando haxa algún problema. Moitas veces é posible arranxar o problema no momento e seguir adiante, pero algunhas veces vai ser necesario interromper a migración mentres estudamos o que facer a continuación.
Isto lévame ao segundo punto: os pasos da migración deben ser reversibles. Imaxinade que estades a facer un cambio complexo nun servizo, atopades un problema e queredes deixalo todo como estaba antes mentres o investigades. Se os cambios non son reversibles, non ides poder desfacelos e ides ter dous problemas no canto dun só.
Hai algúns cambios que son, por natureza, irreversibles (por exemplo, borrar unha columna nunha base de datos). O mellor que podedes facer con eses cambios é deixalos para o final, cando todo o resto da migración xa está feito. Se non podedes facer iso, deberiades preparar o sistema para que poida funcionar co cambio a medio facer. Por exemplo, imaxinade que tedes varias réplicas e a metade está migrada pero a outra metade non; é moito mellor se o voso sistema pode usar todas as réplicas que se só pode usar unha das metades.
Incluso se non hai problemas, é moito mellor facer unha migración gradualmente, pouco a pouco, que ter que facela toda dun golpe. O principal beneficio diso é poder ir observando o comportamento do sistema a cada paso da migración e poder detectar problemas antes de que se fagan grandes de máis. No exemplo de enriba, poderíamos migrar unha réplica cada día e ilas monitorizando todas para ver se funcionan ben e aturan a carga de traballo.
Outro beneficio importante dunha migración gradual é que nos permite executala sen interromper o servizo. Xa teño visto demasiados letreiros de “esta páxina web vai estar pechada durante dous días por mantemento”. As migracións sempre levan máis tempo do que un pensa, polo que se o servizo ten que estar pechado mentres se executan, podemos ter moitos problemas se se demora de máis.
Logo, como podedes cambiar a base de datos do voso sistema?
Obviamente, a resposta non é pechar o sistema, copiar os datos, mudar a configuración e volver abrir o sistema, porque veño de escribir case 600 palabras na contra diso.
O que tedes que facer é usar as dúas bases de datos, lendo e gravando datos nas dúas ao mesmo tempo, e ter un proceso que vaia copiando os datos antigos da base de datos vella á nova. En pouco tempo, sen interrupción do servizo, todos os datos estarán migrados e, despois de vos asegurar de que as dúas bases de datos teñen a mesma información, poderedes pechar a base de datos vella e dar por completada a migración.
1 comentario