Re: Configuración para aplicación

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 <alvherre(at)alvh(dot)no-ip(dot)org>