• Author / Uploaded
• German Martinez

• Categories
• PostgreSQL
• Bases de datos
• Servidor (Informática)
• MySQL
• Archivo de computadora

Citation preview

Replicación en PostgreSQL 9.0

Trabajo de Investigación

Universidad Nacional de Salta Facultad de Ciencias Exactas Base de Datos II Segundo Cuatrimestre 2012 Martínez Moreno, Germán René

Concepto de Replicación La replicación es el proceso de intercambiar datos de transacciones para asegurar la consistencia entre nodos de bases de datos redundantes. Es el proceso de copiar y mantener los elementos de una base de datos en múltiples bases de datos que forman un sistema de bases de datos distribuido. Entre las distintas ventajas que ofrece este proceso encontramos: ➢ Alta disponibilidad (high availability): Se puede incrementar la disponibilidad de una base de datos mediante la replicación en un sistema distribuido. Si una de las máquinas del sistema falla, las otras podrán satisfacer las necesidades del cliente. ➢ Balance de carga (load balancing): La replicación se puede utilizar para hacer un balance de carga. Ésta es una técnica usada para compartir el trabajo a realizar entre varias computadoras. ➢ Soporte para aplicaciones de alto consumo: Se puede satisfacer las necesidades de ciertos clientes que requieren un alto consumo en consultas, que sería muy costo en rendimiento, o hasta imposible, en una base de datos sin replicación. ➢ Confiabilidad: Debido a que existen varias copias de los datos disponibles en el sistema, se cuenta con un mecanismo confiable de recuperación de datos ante fallos en algún nodo. Los servidores de bases de datos de sólo lectura son relativamente fáciles de combinar, ya que los datos de sólo lectura deben ser almacenados sólo una vez en cada servidor. Sin embargo, la mayoría de los servidores de bases de datos tienen consultas variadas de lectura y escritura. Este tipo de servidores son mucho mas difíciles de combinar debido a que una consulta de escritura hecha a un servidor debe poder actualizar el resto de los servidores para que en las próximas consultas puedan entregar datos consistentes. Con la replicación surgen los problemas de sincronización. Existen distintos modelos que dan solución a este problema, cada uno lo enfoca de manera distinta. Replicación síncrona: una transacción de modificación de datos no es considerara hasta que todos los servidores confirmaron la transacción. Esto garantiza que ante un eventual error en la transacción no se perderán datos y que todos los servidores de carga balanceada devolverán resultados consistentes sin importar cual de los servidores haya sido consultado. Replicación asíncrona: permiten un retraso entre el momento en que se realiza una consulta y el tiempo de propagación a los otros servidores. Aquí existe la posibilidad de que algunas transacciones se pierdan cuando se cambia a un servidor de respaldo y que los servidores de carga balanceada devuelvan resultados ligeramente antiguos. La comunicación asíncrona es utilizada cuando la comunicación sincrónica sería muy lenta. Algunas soluciones permiten modificar los datos solo a un servidor. A este servidor se lo conoce como servidor de lectura/escritura (read/write server), primario (primary server), o maestro (master server). Los servidores que rastrean los cambios del maestro son llamados servidores de reserva (standby servers), o esclavos (slave servers). Un servidor de reserva que no puede ser conectado hasta que sea ascendido al nivel de servidor maestro se llama servidor en espera semiactiva (warm standby server) y uno que acepta conexiones y sirve a consultas de sólo lectura es llamado servidor de reserva “caliente” (hot standby server). 2 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Modelos de Replicación de Datos Shared Disk Failover Este método evita el sobrecargo de sincronización utilizando una sola copia de la base de datos. Usa un arreglo de disco simple que es compartido por múltiples servidores. Si el servidor principal de la base de datos falla, el servidor standby es capaz de montarse y empezar la base de datos como si se tratase de una recuperación de una caída de la base de datos. Esto permite una recuperación rápida y sin pérdida de datos. File System Replication Una versión modificada de la funcionalidad del hardware compartido es la replicación del sistema de archivos, donde todos los cambios de dicho sistema están duplicados en el sistema de archivos de otra computadora. La única restricción es que la duplicación debe ser hecha de manera tal que se asegure que el servidor standby tiene una copia consistente del sistema de archivos. Transaction Log Shipping Los servidores warm standby y hot standby pueden mantenerse actualizados leyendo un flujo de registros de WAL (write-ahead log). Si el servidor principal falla, el servidor standby contiene casi todos los datos del servidor pincipal, y puede ser rápidamente convertido en el nuevo servidor master. Este modelo puede ser sincrónico o asincrónico, y sólo puede ser implementado para el servidor de base de datos completo. Trigger-Based Master-Standby Replication Este tipo de replicación envía todas las consultas de modificación de datos al servidor master. El servidor master envía asincrónicamente las modificaciones de los datos al servidor standby. Éste último puede responder consultas de sólo lectura mientras el servidor master esta corriendo. Statement-Based Replication Middleware Con este tipo de replicación, un programa intercepta todas las consultas SQL y las envía a uno o todos los servidores. Cada servidor opera independientemente. Las consultas de lectura-escritura deben ser enviadas a todos los servidores, así todos los servidores reciben cualquier cambio efectuado. Pero las consultas de sólo lectura pueden ser enviadas a un único servidor, permitiendo la distribución de carga de trabajo de lectura a través de los servidores disponibles. Asynchronous Multimaster Replication Para los servidores que no están conectados regularmente, mantener los datos consistentes a través de estos es un gran desafío. Usando este tipo de replicación, cada servidor trabaja de manera independiente y periódicamente se comunica con los otros servidores para identificar las transacciones conflictivas. Estos conflictos pueden ser resueltos por el usuario o por reglas de resolución de conflictos. Synchronous Multimaster Replication En este tipo de replicación, cada servidor puede aceptar solicitudes de escritura y los datos modificados son transmitidos desde el servidor original al resto de los servidores antes de que cada transacción sea confirmada. Una fuerte actividad de escritura puede causar un bloqueo excesivo, causando un bajo rendimiento. Las solicitudes de lectura pueden ser enviadas a cualquier servidor.

3 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Replicación nativa en PostgreSQL A partir de la versión 9.0 de PostgreSQL, se incluye la función de replicación como parte de su núcleo. El modelo que se implementa es el Transaction Log Shipping, conocido como: Streaming Replication con la opción Hot Standby, que permite que el/los servidores standby puedan responder consultas de sólo lectura. Ficheros WAL Los ficheros WAL (Write Ahead Log) son utilizados por PostgreSQL para guardar toda la información sobre las transacciones y cambios realizados en la base de datos. Son utilizados para garantizar la integridad de los datos almacenados en la base de datos. También se utilizan para reparar automáticamente posibles inconsistencias en la base de datos después de una caída del servidor. Estos ficheros tienen un nombre único y un tamaño por defecto de 16 Mb. Cada vez que ocurre una transacción en la base de datos, se escribe en uno de estos archivos, así, si hay algún problema, se puede recurrir a los archivos WAL para recuperar dicha transacción. Streaming Replication con Hot Standby Este tipo de replicación es asincrónica, entre un servidor master y uno o varios servidores standby. Se basa en la transferencia de registros WAL (no de archivos completos), lo que permite mantener una copia bastante actualizada del servidor. Funciona de la siguiente manera: El servidor master tiene un procedimiento llamado WALSender, que se encarga de enviarle el registro WAL a los servidores standby. Cada servidor standby tiene un procedimiento WALReceiver que recibirá el registro WAL enviado por el servidor master. La característica Hot Standby permite que el servidor standby responda a consultas de sólo lectura, de esta manera se puede balancear la carga del servidor master distribuyendo las consultas a los otros servidores. Existe un problema con esta solución y es que hay que tener cuidado de que los archivos WAL en el servidor master no sean reciclados antes de ser enviados al servidor standby. No deberíamos preocuparnos por esto si disponemos de suficiente espacio para tener un gran número de archivos WAL (incrementar el número de wal_keep_segments, cada uno necesita 16 Mb) y/o la base de datos no es muy activa. En caso de que no se pueda asegurar eso, se puede complementar la replicación con una solución conocida como File-based Log Shipping, (implementada de forma nativa desde PostgreSQL 8.3), que consiste en el envío periódico de archivos WAL al servidor standby. También se podría optar por la solución File-based Log Shipping sin utilizar Stramig Replication, pero ante una caída del servidor principal se pueden perder las últimas transacciones realizadas. Por lo tanto, la manera de realizar un sistema de replicación robusto es utilizando una combinación de ambas soluciones, como vemos en la siguiente imagen y como vamos a utilizar en el ejemplo de implementación. 4 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Sistema de replicación utilizando Streaming Replication y File-based Log Shipping.

How to Streamin Replication/Hot Standby Para el desarrollo de un ejemplo de aplicación de replicación en PostgreSQL, vamos a utilizar dos máquinas con las siguientes características: Nodo Servidor: Procesador AMD Athlon X2 5600 Memoria 2 GB DDR2 Disco rígido 500 GB Sistema Operativo: GNU/Linux Ubuntu 12.10 64 bits. IP de red: 192.168.0.20 Nodo Standby: Procesador Intel Pentium Dual Core T4500 Memoria 4 GB DDR3 Disco Rígido 500 GB Sistema Operativo: GNU/Linux Ubuntu 12.10 64 bits. IP de red: 192.168.0.21 Versión en ambos nodos: PostgreSQL 9.2 Directorio de instalación de PostgreSQL en ambos nodos: /opt/PostrgeSQL/9.2/ Directorio de datos de PostgreSQL en ambos nodos: /opt/PostrgeSQL/9.2/data/ Debemos tener instalado OpenSSH Server en ambos nodos. Se utiliza una conexión wi-fi con un router Motorola SBG901 de Fibertel. Si bien, por motivos de eficiencia en la velocidad de conexión no es recomendable utilizar redes inalámbricas, para este ejemplo la vamos a utilizar por cuestiones prácticas. 5 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

En el servidor master está instalada la base de ejemplo northwind y una base de prueba llamada prueba01. Es importante saber que Streaming Replication no nos permite elegir la base de datos a replicar, por lo tanto, si hubiese otras bases en el nodo master también se replicarían. Lo primero que debemos hacer es detener el servicio de PostgreSQL en el servidor esclavo: sudo service postgresql­9.2 stop  Creamos una carpeta en el servidor standby que servirá para que el servidor master transfiera los archivos WAL completos. Estará en el directorio raíz y el propietario será postgres: sudo mkdir /wal sudo chown postgres:postgres /wal Cambiamos el propietario de la carpeta de instalación de PostgreSQL en ambos servidores: sudo chown ­R postgres:postgres /opt/PostgreSQL/ Ahora nos identificamos como el usuario postgres en el servidor maestro para crear el par de claves privadas y públicas: sudo su postgres ssh­keygen ­t dsa Ahora en el servidor esclavo le damos una contraseña temporal al usuario postgres: sudo passwd postgres Desde el servidor maestro, identificados como postgres hacemos: ssh­copy­id ­i /opt/PostgreSQL/9.2/.ssh/id_dsa.pub  [email protected] que instala la credencial en el servidor esclavo. Nos pedirá la contraseña de postgres que le pusimos en el paso anterior. Ya le podemos quitar la contraseña a postgres: sudo passwd ­l postgres Creamos en el servidor standby un archivo llamado recovery.conf que debe ser guardado dentro de la carpeta data de la instalación de PostgreSQL (/op/PostgreSQL/9.2/data en nuestro caso) y que contendrá lo siguiente: restore_command = 'cp /wal/%f %p' standby_mode = on primary_conninfo = 'host=192.168.0.20 port=5432 user=postgres' 6 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

En el archivo postgresql.conf del servidor esclavo habilitamos la opción de Hot Standby: hot_standby = on En el archivo pg_hba.conf del servidor master, añadimos la siguiente linea que habilita al usuario postgres para hacer Streaming Replication: host replication

postgres

192.168.0.21/32

trust

En el servidor maestro, configuramos el archivo postgresql.conf de la siguiente manera: listen_addresses = ‘*’ wal_level = hot_standby archive_mode = on archive_command = 'scp %p 192.168.0.21:/wal/%f' max_wal_senders = 1 wal_keep_segments = 1000 Reiniciamos el servicio en el maestro: sudo service postgresql­9.2 restart Ahora procedemos a crear lo que se conoce como bakup binario en el servidor maestro. Nos identificamos como usuario postgres y accedemos a psql: sudo su postgres /opt/PostgreSQL/9.2/bin/psql En psql iniciamos el backup: select pg_start_backup('backup binario'); Ahora copiamos los archivos del servidor maestro al esclavo, excepto los archivos de configuración: rsync ­a /opt/PostgreSQL/9.2/ 192.168.0.21:/opt/PostgreSQL/9.2/  ­­exclude postmaster.pid ­­ exclude '*.conf' ­­exclude postmaster.opts

En psql de nuevo, detenemos el bakcup: select pg_stop_backup(); Ya terminamos, solo resta iniciar el servicio de PostgreSQL en el nodo esclavo: sudo service postgresql­9.2 start

7 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Comprobando funcionamiento A continuación, una serie de capturas de pantalla que nos muestran que el sistema de replicación funciona correctamente: El escritorio con entorno GNOME 3 es el maestro y el de Unity es el esclavo.

Las bases de datos en el servidor maestro.

8 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Las bases de datos replicadas en el servidor esclavo.

9 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Viendo los datos en la tabla01 de la base de datos prueba01 en el servidor master.

10 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Los datos de tabla01 en la base prueba01 que está en el standby coinciden con los del master.

11 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Insertamos en tabla01 una fila con id = 10 y valor = 16. Se produjo la transacción con éxito.

12 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Como esperábamos, la tupla ingresada anteriormente se ve reflejada en la réplica.

13 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Intentamos ingresar una tupla en el servidor esclavo y no nos permite porque solo responde consultas de sólo lectura (Hot Standby).

14 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Replicación en PostgreSQL con Slony-I Slony-I es un sistema de replicación asíncrona para PostgreSQL del tipo Master → Multi Slave. Realiza las actualizaciones a través de disparadores o triggers. Algunas de las características de Slony-I son: • • • •

Puede replicar datos entre diferentes versiones de PostgreSQL. Puede replicar datos entre servidores con distinto hardware o sistemas operativos. Permite seleccionar qué tablas replicar. Permite elegir en qué servidor esclavo se replicarán las tablas.

Slony-I también está disponible para versiones de PostgreSQL inferiores a la 9.0. Esta solución, al estar basada en triggers presenta ciertas restricciones. Entre las limitaciones de Slony-I tenemos que no puede replicar automáticamente: • • •

Cambios realizados por una consulta DDL. Cambios realizados a usuarios y roles. Cambios en BLOB (Binary Large OBject – Objeto grande binario)

Ejemplo sencillo de aplicación. En este ejemplo voy a trabajar sobre la plataforma Windows 7, para no tener que cambiar la configuración que hice para Streaming Replication. Las IP de red siguen siendo las mismas (192.168.0.20 y 192.168.0.21) y la versión del software es PostgreSQL 9.1. Para instalar Slony-I, vamos a utilizar Stack Builder. El proceso de instalación es muy sencillo e intuitivo.

Instalación de Slony-I con Stack Builder. Los otros pasos los indica el instalador.

15 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Vamos a replicar la base de datos baseslony que está en el servidor master y que cuenta con dos tablas: localidades y provincias. Utilizaremos el super usuario postgres, aunque no es necesario que el usuario tenga privilegios de super. Ambos nodos deben tener la misma base de datos antes de hacer la replicación. Desde el pgAdmin vamos a File → Options → General y en Slony-I Path especificamos el directorio donde se instaló y aceptamos. Ahora debemos editar el archivo pg_hba.conf en el maestro y en el esclavo: #Maestro host #Esclavo host

all

all

192.168.0.20/32

md5

all

all

192.168.0.21/32

md5

Añadimos una excepción al firewall de Windows para el puerto 5432 en cada una de las máquinas para permitir que se comuniquen. Ahora debemos crear un par de scripts que utilizamos para indicar qué tablas queremos replicar y cuál será el nodo maestro y cuál el esclavo. Son los siguientes dos archivos de texto: Maestro.txt: cluster name = pruebaSlony2; node 1 admin conninfo = 'dbname=baseslony host=192.168.0.20 user=postgres  password=adminPC'; node 2 admin conninfo = 'dbname=baseslony host=192.168.0.21 user=postgres  password=adminPC'; init cluster (id=1, comment='Nodo Maestro'); create set (id=1, origin=1, comment='Tablas'); set add table (set id=1, origin=1, id=1, fully qualified  name='public.provincias', comment='Tabla provincias'); set add table (set id=1, origin=1, id=2, fully qualified  name='public.localidades', comment='Tabla localidades'); store node (id=2, comment='Nodo Esclavo', EVENT NODE=1); store path (server=1, client=2, conninfo='dbname=baseslony host=192.168.0.20  user=postgres password=adminPC'); store path (server=2, client=1, conninfo='dbname=baseslony host=192.168.0.21  user=postgres password=adminPC'); store listen (origin=1, provider=1, receiver=2); store listen (origin=2, provider=2, receiver=1);

16 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Esclavo.txt: cluster name = pruebaSlony2; node 1 admin conninfo = 'dbname= baseslony host = 192.168.0.20 user = postgres  password = adminPC'; node 2 admin conninfo = 'dbname= baseslony host = 192.168.0.21 user = postgres  password = adminPC'; subscribe set (id = 1, provider = 1, receiver = 2, forward = yes);

Estos scripts deben ser guardados en el directorio C:\Program Files\PostgreSQL\9.1\bin, el Maestro.txt en el del servidor master y el Esclavo.txt en el del servidor standby. Ahora ejecutamos el script en el nodo maestro con el siguiente comando: C:\Program Files\PostgreSQL\9.1\bin\slonic Maestro.txt Esperamos unos segundos y verificamos que no existan errores. Si todo salió bien, abrimos el pgAdmin y dentro de la base de datos baseslony, en Slony Replication ya nos debe aparecer el cluster pruebaSlony2. Ejecutamos el script del servidor esclavo: C:\Program Files\PostgreSQL\9.1\bin\slonic Esclavo.txt Ahora tenemos que iniciar la replicación en cada nodo. Para ello, primero vamos al servidor maestro y, desde la ruta de la carpeta bin de PostgreSQL ejecutamos el siguiente comando: slon pruebaSlony2 “dbname = baseslony user = postgres password = adminPC” Luego ejecutamos la misma linea desde el nodo esclavo. En mi caso especial, tuve que descargar la librería pthreadVC2.dll y agregarla en la carpeta /bin porque estaba ausente. Ya está en funcionamiento la replicación. Esta se mantendrá funcionando siempre que no se cierren las consolas en las que ejecutamos la última linea. Cada vez que iniciemos el servicio de PostgreSQL debemos volver a ejecutar ese comando. Veamos cómo funciona:

17 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Agregamos la localidad Santa Maria en el maestro.

En menos de 30 segundos aparece en el esclavo la localidad agregada.

18 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Ventajas frente a la replicación nativa • • • •

Interfaz visual que permite configurarlo de manera más intuitiva. Independiente de la plataforma de los nodos. Permite seleccionar qué bases de datos se replicarán. Permite seleccionar qué tablas de la base de datos se replicarán.

Desventajas frente a la replicación nativa • • • •

No replica cambios efectuados por consultas DDL. No replica cambios en los usuarios ni en los roles. No puede repicar automáticamente cambios a BLOBs. Es necesario instalar software adicional.

Replicación en PostgreSQL con RubyRep RubyRep es una herramienta de replicación asincrónica, basada en Ruby que permite crear sistemas de replicación de tipo Master → Master y Master → Slave. RubyRep tiene soporte tanto para PostgreSQL como para MySQL, es independiente de las versiones de las bases de datos y de la plataforma (funciona tanto en Linux como en Windows, aunque en Windows puede tener un rendimiento menor). Estas características hacen de RubyRep una herramienta muy flexible que permite la integración de distintos sistemas. Es fácil de instalar, configurar y monitorear. También es independiente del diseño que tengan las tablas a replicar, es decir, permite tablas con claves primarias simples, combinadas, o incluso sin claves primarias (en este último caso es necesario que exista al menos una columna Unique). Además puede procesar con éxito textos multi-byte y tipos de datos grandes: en PostgreSQL con bytea y text, en MySQL funciona con los BLOB y text. Puede encontrar nuevas tablas añadidas en uno de los nodos y automáticamente sincronizar su contenido. También puede configurar de manera automática disparadores o triggers, tablas de log, etc. Algunas de sus limitaciones son que no permite realizar un balance de carga, no admite lo que se conoce como Connection Pooling (agrupamiento de conexiones), y no puede realizar particionamiento de consultas. Ventajas frente a la replicación nativa • • •

Independiente de plataformas y de versiones de bases de datos. Puede ser usado en PostgreSQL y en MySQL. Permite la replicación Multi Master.

Desventajas frente a la replicación nativa • •

Es necesario instalar software adicional. Menor rendimiento. 19 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Conclusiones Un sistema de replicación es muy importante para una organización que cuenta con información sensible, para aquellas que manejan grandes volúmenes de datos, o para las que utilizan acceso remoto a la información. Contar con un sistema de replicación apropiado va a depender de muchos factores, por lo que es necesario definirlos previamente y que la persona que se va a encargar de implementarlo esté bien informado sobre todas las soluciones que ofrece el mercado. Como podemos ver en el siguiente cuadro, existe una gran variedad de alternativas:

Es importante también destacar que el desarrollo de PostgreSQL está empezando a incluir más características de replicación a medida que salen las nuevas versiones. Un breve repaso de cómo se empezó a incluir estas características nativamente: PostgreSQL 8.3 → Warm Standby PostgreSQL 9.0 → Hot Standby / Streaming Replication PostgreSQL 9.1 → Replicación sincrónica ( Master → Slave). Seguramente en próximas versiones de este motor se incluirán algunas nuevas características o se mejorarán las ya implementadas.

20 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René

Webs consultadas Replicación Nativa http://www.postgresql.org/docs/9.2/static/high-availability.html http://www.postgres-r.org/documentation/terms http://www.corporacionsybven.com/portal/index.php? option=com_content&view=article&id=384:replicacion-de-datos&catid=124:conceptos-teoricos http://es.scribd.com/doc/70420722/REPLICACION http://www.postgresql.org.es/node/483 http://www.themagicnumber.es/replication-in-postgresql-i?lang=es http://www.themagicnumber.es/replication-in-postgresql-ii-hot-standbystreaming-replication? lang=es http://wiki.postgresql.org/wiki/Streaming_Replication http://www.howtoforge.com/how-to-set-up-a-postgresql-9.0-hot-standby-streaming-replication-serv er-with-repmgr-on-opensuse-11.4 http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial Slony-I http://slony.info/documentation/2.1/index.html http://www.howtoforge.com/configuring-slony-i-cascading-replication-on-postgresql-8.3 http://www.slideshare.net/JohannaMendez2/replicacion-con-postgresql-y-slony http://basesdedatosues.blogspot.com.ar/2010/06/replicacion-postgresql-slony-i.html RubyRep http://www.rubyrep.org http://www.rubyrep.org/features.html http://www.slideshare.net/denishpatel/yet-another-replication-tool-rubyrep http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

21 U.N.Sa. - Base de Datos II – 2012 – Martínez Moreno, Germán René