Tengo la siguiente situación: tengo tres máquinas que ejecutan bases de datos postgresql. Una máquina contiene información de la cuenta del cliente (llame a esta máquina C), las otras dos máquinas contienen información de registro del cliente (llame a estas L1 y L2). La razón de la división es separar la carga en varias máquinas (por lo que algunos clientes envían información de registro a L1, algunos a L2 ... y tal vez a veces L3, L4, ...).
Al recuperar la información de registro, en principio, me gustaría poder unirme entre las tablas de registro en Ln y las tablas de la cuenta del cliente en C. En realidad, no puedo unirme de esta manera (e incluso si pudiera, me gustaría para evitar cargar C).
Mi pensamiento es replicar las tablas en C en cada uno de L1, L2, ... para que pueda hacer las uniones. En lo que respecta a las tablas de C, C es maestro y L1, L2, ... son esclavos. Pero para las otras tablas en L1, L2, ... estas máquinas son maestras. No es exactamente la replicación maestro-maestro, y tampoco es exactamente maestro-esclavo.
¿Se puede persuadir a la replicación de postgres (estoy ejecutando 9.1) para que haga esto, o si no hay otros paquetes que hagan el trabajo? En el último recurso, puedo escribir un código que sincronice periódicamente las tablas (puedo tolerar algún retraso), ¡pero sería bueno no hacerlo!
Gracias por adelantado.
Respuestas:
En PostgreSQL 9.3, puede utilizar
postgres_fdwpara consultar de forma transparente la tabla externa en la otra máquina.En versiones anteriores,
dblinkpuede ser una opción mencionada por Andrew.Otra opción es utilizar una herramienta como Londiste o Slony-I para replicar las tablas que desee. Recomiendo usar Londiste para esto, será mucho más simple. Crea activadores en la tabla para detectar inserción / actualización / eliminación, y los replica utilizando su propio cliente / servidor y un sistema de colas en la otra base de datos, donde realiza la inserción / actualización / eliminación correspondiente. Lo uso en producción en varios sitios de clientes y funciona muy bien.
Una opción futura (con suerte en PostgreSQL 9.5) será la replicación lógica de transmisión de registros, la extracción de conjuntos de cambios lógicos y la replicación bidireccional, lo que permitirá replicar bases de datos o tablas individuales a nivel de SQL. Parte del trabajo para esto se comprometió con PostgreSQL 9.4, pero no lo suficiente como para que sea útil para lo que desea hacer.
fuente
Debería usar dblinks y vistas materializadas para lograr esto. Ambas características están integradas en las últimas versiones de Postgres:
http://www.postgresql.org/docs/9.3/static/rules-materializedviews.html
http://www.postgresql.org/docs/9.3/static/dblink.html
Esencialmente, crea un Mview en cada base de datos L1, L2 ... con datos extraídos de las tablas en C, luego usa Mview refresh para actualizar periódicamente los Mviews con la frecuencia que sea necesaria. Los datos se almacenan localmente, por lo que acceder a ellos es muy rápido. Esto solo es adecuado si los datos son relativamente estáticos y no le importa que las bases de datos locales ocasionalmente tengan información ligeramente desactualizada. Debe configurar las frecuencias de actualización para administrar esto de manera adecuada, y si no es aceptable, simplemente debe usar un enlace de base de datos y lidiar con la lentitud resultante.
Si necesita una funcionalidad adicional, el proyecto de instantáneas proporciona características avanzadas como actualizaciones rápidas y registros de instantáneas:
http://pgfoundry.org/projects/snapshot/
Con esto, puede realizar las actualizaciones solo actualizar las filas que necesitan actualización, lo que puede hacer que sean extremadamente rápidas para grandes conjuntos de datos inelásticos, minimizando la interrupción de su aplicación. Por defecto, las vistas Mviews se eliminan y recrean por completo en Postgres, lo que puede ser muy malo para el rendimiento por razones obvias.
fuente