jajajja, Buen sentido del humor para este problema!
Eduardo Arenas. 2012/2/6 Alvaro Herrera <alvhe...@alvh.no-ip.org> > > Excerpts from Juan Romero's message of lun feb 06 12:20:01 -0300 2012: > > Un amigo me pregunta lo siguiente, y quisiera que me ayudaran con sus > > opiniones al respecto: > > > > Se está desarrollando una aplicación de seguimiento vehicular (AVL). > > Como Servidor de Mapas estamos usando Geoserver y como Repositorio de > > BD estamos usando PostgreSQL + PostGIS, este ultimo para realizar > > consultas espaciales directamente con la DB. > > > > Unos equipos GPS están enviando información. Esta información es leída > > e interpretada mediante un listener que escucha un socket, con lo que > > estamos poblando un par de tablas en la DB. Se esperan 20.000 GPS > > enviando información > > > > Quieren tener una copia de la DB en otro server esclavo y/o de > replicación. > > > > 1. Dado que en la versión 9.1 tenemos replicación síncrona, pero que > > existen otras opciones, no tengo claro que tipo de replicación se debe > > hacer. > > La replicación síncrona no es muy conveniente, porque en cuanto el > standby se cae, el maestro deja de aceptar nuevos commit de > transacciones. Me parece que replicación asíncrona es mejor para tu > caso: siempre tendrás casi todo en la réplica; y si el maestro estalla, > podrás recuperar desde la réplica con mínima pérdida. Si es la réplica > la que estalla, el maestro sigue procesando nuevos datos. En ambos > casos estoy pensando en "streaming replication". > > > 2. En el momento tengo 1 servidor (Worksatation Dell Precision 690) > > Dell con 1 Procesador Dual Core XEON de 2.33Ghz, Ram 8Gb, HD 750 GB en > > raid 0 (Gemelos), con sistema operativo Mandriva Linux 2011. También > > tengo disponible una maquina Dell Core 2 Quad, Ram 4Gb, HD 1TB. Esta > > ultima para las replicas o lo que se requiera. > > ¿20.000 GPS en operación enviando datos y no tienen fondos para comprar > un buen juego de discos? Me imagino que deben haber implantado chips > GPS a los vagabundos de la calle, con dinero fiscal, y se quedaron sin > fondos para proveer de hardware a la solución de almacenamiento. > ¿O quizás Greenpeace está empezando un seguimiento masivo de ballenas, y > todavía no reciben mi donación? > > Mandriva ... ¿no era la que quebró como en 2007? Creo que volverá a > quebrar este año. ¿Será la mejor opción? http://bit.ly/w1B09h > > > 3. Cuáles serian las mejores prácticas de configuración de la DB y de > > la gestión de cola, ya que el número de usuarios es directamente > > proporcional con el número de equipos GPS enviando información a la DB > > y que el Listener debe interpretar y almacenar. > > Usando commit asíncrono le darías respuesta rápida a cada requerimiento > de commit de inserción; el commit debería ser síncrono para otro tipo de > transacciones. Así puedes sobrellevar la carga sin matar el sistema. > > Me imagino que pondrás el listener en una (o unas) máquina remota que se > conecte vía TCP al maestro. De este modo, si el maestro es acuchillado, > el listener se da cuenta, espera hasta que la réplica levanta como > maestro, y se conecta al nuevo maestro para continuar la inserción, sin > pérdida de servicio. > > -- > Álvaro Herrera <alvhe...@alvh.no-ip.org> > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda >