Hola Alvaro y general lista Muchas gracias por todos sus aportes!!! , voy a tratar de configurar un entorno que me permita obtener tráfico de producción en pruebas y verificar el funcionamiento de las secuencias globales en un ambiente más real .. Les estaré informando... Hellmuth Vargas escribió:
> Si tiene razón, emplee generate_series() con el fin de verificar el > comportamiento con miles de transacciones pero no seria el nivel real de > transacciones en mi caso, aunque el escenario que estamos planteando para > la empresa si tiene un alto nivel de transacciones concurrentes pues en la > base de datos almacenan todos los eventos de las llamadas, IVR, logs de > operación, calificación y otros datos relevantes... Hmm. Para estas cosas lo importante es la latencia, ¿no? Si el servidor BDR se "bloquea" de uno a diez segundos cada cinco minutos, puede ser fatal. ¿O tienes cierta tolerancia a un pico ocasional de latencia? Lo que te iba a decir es que la manera más conveniente de lidiar con este problema es hacer un bucle de reintento: cada vez que te sale un error de la secuencia, haz dormir 100ms a la aplicación y luego trata otra vez la transacción; repite hasta que funcione. Es lo que recomienda la página de secuencias globales que citó Jaime. > Si, si lo tengo claro pero cuanto debería ser este tiempo de propagación > razonable... pues en le esquema que estoy probando están montados en la > misma maquina con diferente puerto, y no se penaliza por red y otros > factores... Entiendo que unos pocos segundos o un par de minutos. Depende de la carga: mientras más cargados estén los servidores, más retardo habrá. En un servidor de pruebas donde estés ejecutando órdenes SQL interactivamente, el retardo será casi cero. Corolario: puedes disminuir el retardo mejorando el hardware. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
