Así que estoy intentando migrar un sitio restaurando una copia de seguridad de un despliegue existente. Estoy recibiendo un error de restauración debido a la discrepancia de esquemas (la fuente es más nueva que el destino).
Ahora estoy revisando el punto final de admin/plugins para ambos despliegues y coinciden para los que están listados, su estado y su versión, así que me estoy rascando la cabeza un poco. También intenté volver a instalar todos los Temas y Componentes por si acaso y no hubo cambios. Ambos sitios están en la aplicación 3.1.3, así que eso no parece ser la causa raíz en este caso.
Supongo que hubo un plugin instalado en el sitio, luego la instancia fue redeseployada y la base de datos se conservó sin este plugin instalado, pero eso es solo una suposición. ¿Hay una forma determinista dado una instancia o base de datos que pueda averiguar qué contribuyó a la deriva del esquema? ¿Y hay una forma de “revertir” o es el único método hacer que el sitio de destino coincida o sea un superconjunto?
¿Podría ser que el anterior estuviera en beta o que las pruebas pasaran y no fueran estables, por lo que la última versión estable sea, de hecho, más antigua?
Verificaría que los números de commit coincidan (si es posible).
La copia de seguridad es de la base de datos, así que dudo que la población de plugins importe, simplemente añadirá los datos del plugin pero no los utilizará realmente…
No lo creo, pero es un entorno de desarrollo, así que supongo que todo es posible.
¿Hay algo que sepas en la tabla schema_migrations (o en el código clonado del contenedor) que pueda comprobar manualmente y correlacionar la versión del esquema con algún cambio?
El cambio de nombre del archivo permite subir cosas a través de la interfaz de usuario, pero estaba usando el merger que se bloquea basándose en max(schema_migrations) y realmente estoy tratando de evitar modificar las cosas demasiado.
Parte de esto se está adelantando a cualquier tarea operativa donde puedan aparecer discrepancias en la versión de migración. Es mejor entender cómo rastrear la versión de migración hasta los cambios para que, cuando esto vuelva a suceder, pueda, con suerte, encontrar un manual para reconciliar.
Sí, puedo ver la schema_migration máxima (incluso solo mirando el nombre de archivo de una copia de seguridad), pero revisé la tabla y solo tiene el valor de la fecha. No hay indicaciones de dónde provino.
Por ejemplo, el “bueno” es 20230823100627 y el sitio es 20231022224833. Ni siquiera puedo encontrar archivos para “20231022” en la carpeta post_migrate (o en cualquier otro lugar del repositorio).
Estoy seguro de que está justo delante de mí. Y sí, estoy revisando cambios pasados y correos electrónicos para intentar averiguar si puedo relacionar alguna acción después de agosto en la que una versión errónea podría haberse colado.
En este caso, es la instancia de Dev a una instancia de “Merge” recién aprovisionada que luego usaré para importar otra instancia de Dev como esfuerzo de consolidación de instancias de prueba que estamos llevando a cabo. La versión de migración de esquema que está sincronizada es un requisito previo (no me sorprende). En este caso, el entorno de destino está en 1022 y el origen es 0823. En todas las 3.1.3 que tengo, somos 0823, por lo que ha sido un rompecabezas de dónde provino 1022 y eso es lo que estoy tratando de averiguar, pero no puedo encontrar rastro.
Idealmente, no deberías necesitar mantener ningún dato en dev y deberías poder simplemente descartar la base de datos y volver a ejecutar las migraciones.
Para fusionar dos instancias de desarrollo divergentes, normalmente fusionarías el código de las ramas, incluidas las migraciones, y luego crearías una nueva instancia desde cero.
Esto es en parte por lo que existe una buena tarea de rake para pre-poblar algunas configuraciones de prueba para que haya algo con lo que trabajar: rake dev:populate
Tenemos una base de datos con todos los ID de migración para más de 400 complementos, por lo que podemos mapearlos fácilmente a un complemento. Este proviene de discourse-automation.
Sí, sí, todos los animales de la granja escaparon del granero hace un tiempo, así que estoy intentando que todos vuelvan al corral. O al menos averiguar si es factible.
La gente había estado mirando la automatización, pero en los otros entornos nunca la habían activado, por lo que estaba disponible en la lista de complementos y no se había realizado ningún cambio en el esquema. Así que, lejos de ser ideal, la pista para mí en este trabajo es revisar los repositorios de todos los complementos instalados, incluso si están deshabilitados, ya que tal vez se habilitaron en algún momento.
Estamos haciendo un redespliegue eliminando algunos de estos complementos de I+D, además de vigilar mucho más de cerca las entradas de complementos/bases de datos y llevar un mejor registro allí.
Sí, finalmente lo descubrimos también al observar el tiempo de ejecución de la instancia en sí, pero lejos de ser lo ideal. Lección aprendida para un manual de operaciones si lo necesitamos. Simplemente no revisé el repositorio de automatización en la organización, ya que parecía estar deshabilitado y no había registro de que nadie lo usara. Mala suposición de mi parte.
@RGJ ¿Hay alguna posibilidad de que esa base de datos sea accesible públicamente en algún lugar? Usar el sistema de archivos de la instancia “funciona”, pero se vuelve más complicado de lo que preferiría.
Sí, estaba buscando en el propio repositorio de discourse en lugar de rastrear el mundo, ya que no estaba seguro de si aparecería. Buscar sin un ámbito es demasiado costoso, pero no salí a la organización para ver si había resultados para los esfuerzos oficiales de Discourse.
Tenemos 3 o 4 instancias de Discourse que equipos independientes iniciaron para resolver un problema de negocio compartido y estamos viendo si podemos incorporar a todos en una sola instancia sin perder su trabajo anterior.
No puedo creer que sea una buena práctica depender de la retención de datos en el entorno de desarrollo.
Si los datos son importantes, ese trabajo debería existir en Producción bajo circunstancias más controladas.
No conozco la naturaleza completa de lo que intentas hacer, pero siendo una opinión, las soluciones deberían ser casi con seguridad plugins que se puedan implementar en cualquier lugar y que ni siquiera tengan que depender completamente de una versión específica de Discourse, ni preocuparse si los datos específicos se pre-poblan fuera de la siembra de sus propios fixtures.
En este caso, estamos evaluando la viabilidad de estas operaciones de fusión para las instancias de producción utilizando un par de instancias de desarrollo. Si podemos hacer que el manual sea sólido, entonces todos los datos e instancias serán de nivel de producción, pero hasta ahora han sido mantenidos por equipos independientes. Por lo tanto, saber cuáles son los bloqueos para tener una fusión exitosa es en lo que estoy trabajando ahora. Y la versión del esquema es claramente una clave y tanto la aplicación como los complementos pueden y afectarán la “fusibilidad”. Afortunadamente, las instancias de producción han mostrado 0823, por lo que este problema específico no ocurriría en una ejecución de producción, pero saber cómo analizar una deriva de esquema era necesario y realmente ayudará a nuestros opdocs.
Descubrí otro matiz de los esquemas. Así que eliminamos el plugin de automatización del despliegue y lo volvimos a desplegar. Luego noté que schema_migration parecía volver a 0823 como el último. Así que pensé que estaba listo para ir sin instalar el plugin de automatización en la instancia que estoy fusionando. Bueno, cuando volví a ejecutar la importación, obtuve un error PG::UndefinedTable: ERROR: relation "discourse_automation_automations" does not exist, por lo que, aunque la versión de las migraciones se revirtió, los cambios de esquema asociados a ella en la base de datos real parecían seguir ahí.
(que puedes obtener con 
