Pregunta

Estoy tratando de depurar un problema que comenzó recientemente en mi aplicación Rails (3.0.9), en la que los casos de la aplicación deben reiniciarse (no redistribuirse) cuando se realiza una migración no rota en la base de datos. Esto no solía suceder, y no puedo encontrar una razón por la que debería haber comenzado recientemente.

Mi entorno de producción tiene algunos servidores, cada uno de los cuales está utilizando instancias de unicornio bifurcados, todos compartiendo una sola instancia de MySQL. Cada instancia está utilizando un grupo de conexión de 1. También tengo un servidor que se usa como un entorno de puesta en escena final para probar con datos en vivo, después de probar una base de datos de puesta en escenario.

En el pasado, hemos podido ejecutar migraciones en la base de datos de producción sin redistribuir o incluso reiniciar los servidores de unicornio de producción siempre que fueran migraciones que el código anterior nunca necesitaba ver. Por ejemplo, agregar un campo nuevo y opcional a una tabla existente: el código implementado en el servidor de puesta en escena le escribiría datos, pero los servidores existentes podrían ignorarlo felizmente y continuar usando el DB de la misma manera que lo había sido hasta que lo hubiera sido hasta que nosotros 'Reade para llevar el nuevo código a la producción.

Recientemente, sin embargo, hemos estado viendo una excepción lanzada por los servidores de producción después de ejecutar la migración, pero solo cuando intenta insertar una nueva fila en la tabla modificada. Todas las demás partes de la aplicación, y todas las demás tablas, no se ven afectadas, pero tan pronto como hay un inserto, obtenemos esto:

NoMethodError: undefined method `name' for nil:NilClass

[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:56:in `visit_Arel_Nodes_InsertStatement'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:55:in `map'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:55:in `visit_Arel_Nodes_InsertStatement'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:15:in `send'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:15:in `visit'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:5:in `accept'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:18:in `accept'
[GEM_ROOT]/bundler/gems/rails-83fb5552b6ab/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:111:in `with_connection'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:16:in `accept'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/tree_manager.rb:20:in `to_sql'
[GEM_ROOT]/gems/arel-2.0.10/lib/arel/select_manager.rb:217:in `insert'

El problema desaparece si luego reiniciamos los servidores de producción, a pesar de que todavía están ejecutando el código anterior. Por lo tanto, parece que algo se corrompe en la conexión cuando la tabla se modifica, a pesar de que la aplicación, si no hubiera afectado este error, estaría bien continuando haciendo lo que estaba haciendo antes de la migración.

Invié un poco en Activerecord/Arel, pero lo máximo que puedo hacer es teorizar que en algún momento el modelo en caché de esta tabla pierde cualquier conocimiento de las columnas que tiene, pero no puedo ver por qué haría eso o por qué esto Estaría sucediendo de repente.

No hay solución correcta

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top