Replicació bàsica i connection pooling

La replicació streaming permet crear répliques de lectura per distribuir la càrrega i garantir la disponibilitat. Un connection pooler (com PgBouncer a PostgreSQL, o l'equivalent a cada motor) gestiona el pool de connexions per evitar la saturació del servidor quan hi ha molts clients concurrents.

Per què replicar?

Una sola instància d'un SGBD relacional té tres limitacions estructurals que la replicació resol:

Escalabilitat de lectura: En moltes aplicacions, el 80-90% de les consultes són lectures. Si totes van al mateix servidor, aquest es converteix en el coll d'ampolla. Amb répliques de lectura, les consultes SELECT es poden distribuir entre diversos servidors, multiplicant la capacitat de resposta sense tocar l'aplicació (amb un load balancer davant).

Alta disponibilitat: Si el servidor primari falla, una réplica sincronitzada pot assumir el rol de primari en qüestió de segons (failover), minimitzant el temps d'interrupció del servei.

Backup en calent: Es pot fer un backup físic o lògic sobre una réplica sense afectar el rendiment del primari (per exemple, amb pg_basebackup a PostgreSQL, o l'eina equivalent de cada motor). La réplica absorbeix la càrrega del backup.

Aquestes tres raons (escalabilitat de lectura, alta disponibilitat, backup en calent) són universals: tots els SGBD relacionals importants implementen algun mecanisme de replicació per resoldre-les, encara que l'arquitectura interna i la terminologia varien força d'un motor a l'altre.

Replicació streaming: arquitectura (exemple de PostgreSQL)

Per il·lustrar el principi general amb un cas concret, vegem com ho fa PostgreSQL: utilitza el Write-Ahead Log (WAL) com a base de la replicació. Cada canvi a la base de dades s'escriu primer al WAL abans d'aplicar-se a les pàgines de dades. La replicació streaming envia aquest WAL en temps real des del primari a les répliques:

Aplicació escriu
       |
       v
[Primari PostgreSQL]
  - WAL sender process
       |  (flux WAL per xarxa)
       v
[Réplica 1 (standby)]        [Réplica 2 (standby)]
  - WAL receiver process       - WAL receiver process
  - Aplica canvis               - Aplica canvis
  - Només lectura               - Només lectura

Arquitectura de replicació a altres motors

Tot i que el principi de fons (registre de canvis que es transmet i s'aplica a una còpia) és comú, cada motor té una arquitectura i una terminologia pròpies:

• MySQL/MariaDB es basa en el binary log (binlog): el servidor primari ("source", abans anomenat "master") escriu cada canvi al binlog; les rèpliques ("replicas", abans "slaves") el descarreguen i l'apliquen mitjançant dos fils d'execució: el thread I/O (descarrega el binlog del primari) i el thread SQL/applier (l'aplica a les dades locals). Des de MySQL 5.6 existeix la identificació de transaccions amb GTID (Global Transaction Identifier), que simplifica molt el failover perquè cada transacció té un identificador únic global en lloc d'una posició de fitxer/offset.
• SQL Server fa servir com a tecnologia de referència moderna els Always On Availability Groups (AG): el "transaction log" es transmet en temps real a una o més rèpliques secundàries dins d'un grup de disponibilitat, gestionat per un Windows Server Failover Cluster (WSFC) o, des de SQL Server 2017, també a Linux amb Pacemaker. Existeixen tecnologies més antigues —Log Shipping i Database Mirroring (aquesta darrera, obsoleta des de SQL Server 2012)— que es poden trobar en sistemes heretats però que els AG han substituït com a solució recomanada.
• Oracle fa servir Data Guard, amb dos modes principals: Physical Standby, que aplica el redo log a nivell de bloc (equivalent conceptual a la replicació streaming de PostgreSQL), i Logical Standby, que aplica els canvis com a sentències SQL (equivalent conceptual a la replicació lògica). Data Guard requereix Oracle Database Enterprise Edition.

La taula següent recull l'equivalència de terminologia entre motors:

Concepte	PostgreSQL	MySQL/MariaDB	SQL Server (AG)	Oracle (Data Guard)
Servidor d'origen	Primari	Source (abans master)	Rèplica primària de l'AG	Base de dades primària
Servidor de còpia	Réplica / standby	Replica (abans slave)	Rèplica secundària de l'AG	Base de dades standby
Registre de canvis transmès	WAL (Write-Ahead Log)	Binlog (binary log)	Transaction log	Redo log
Mecanisme d'aplicació física	Replay del WAL	Thread SQL/applier	Redo a la rèplica secundària	Physical Standby (a nivell de bloc)
Mecanisme d'aplicació lògica	Replicació lògica (logical decoding)	— (binlog en format ROW/STATEMENT)	—	Logical Standby (SQL Apply)
Tecnologia de failover automàtic	Patroni (extern)	InnoDB Cluster / Group Replication, Orchestrator	WSFC / Pacemaker (integrat a l'AG)	Fast-Start Failover (Data Guard Broker) o Oracle RAC

Configuració bàsica de replicació streaming a PostgreSQL

Al servidor primari (postgresql.conf)

# Activar l'arxivat del WAL i la replicació
wal_level = replica          # mínim per a replicació; 'logical' per a replicació lògica
max_wal_senders = 5          # màxim de répliques simultànies
wal_keep_size = 1GB          # quant WAL conservar per si la réplica es queda enrere
listen_addresses = '*'       # escoltar a totes les interfícies

Al fitxer pg_hba.conf del primari

# Permet connexions de replicació des de la IP de la réplica
host  replication  replicador  192.168.1.20/32  scram-sha-256

Creació de l'usuari de replicació al primari

CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'contrasenya_segura';

Inicialització de la réplica

# A la màquina réplica: copiar les dades del primari
pg_basebackup \
  --host=192.168.1.10 \
  --username=replicador \
  --pgdata=/var/lib/postgresql/17/main \
  --wal-method=stream \
  --progress \
  --verbose

Configuració de la réplica (postgresql.conf i standby.signal)

# postgresql.conf de la réplica
primary_conninfo = 'host=192.168.1.10 port=5432 user=replicador password=contrasenya_segura'
hot_standby = on   # permet consultes de lectura mentre rep WAL

# Crear el fitxer que indica a PostgreSQL que és una réplica (PG12+)
touch /var/lib/postgresql/17/main/standby.signal

Amb PostgreSQL 17, ja no cal recovery.conf (eliminat a PG12); tota la configuració va a postgresql.conf i el fitxer standby.signal n'indica el mode standby.

Configuració bàsica de replicació a MySQL/MariaDB

A diferència de PostgreSQL, MySQL/MariaDB no transmet pàgines de dades sinó el binlog: un registre seqüencial de totes les sentències (o files modificades, segons el format) que el primari aplica. La rèplica descarrega aquest binlog i el reaplica localment.

# my.cnf del primari (source)
[mysqld]
server-id = 1
log_bin = mysql-bin
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW

-- Al primari: crear usuari de replicació
CREATE USER 'replicador'@'%' IDENTIFIED BY 'contrasenya_segura';
GRANT REPLICATION SLAVE ON *.* TO 'replicador'@'%';

# my.cnf de la rèplica
[mysqld]
server-id = 2
relay_log = relay-bin
read_only = ON

-- A la rèplica: configurar la connexió al primari (GTID-based, MySQL 8.0+)
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST = '192.168.1.10',
    SOURCE_USER = 'replicador',
    SOURCE_PASSWORD = 'contrasenya_segura',
    SOURCE_AUTO_POSITION = 1;

START REPLICA;

-- Verificar l'estat
SHOW REPLICA STATUS\G
-- Camps clau: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source

GTID simplifica el failover

Abans de GTID, calia especificar manualment el fitxer i la posició del binlog (MASTER_LOG_FILE, MASTER_LOG_POS) en reconfigurar una rèplica, un procés propens a errors. Amb SOURCE_AUTO_POSITION = 1 i GTID activat, MySQL determina automàticament des d'on cal començar a replicar, fins i tot després d'un failover entre diverses rèpliques.

Configuració bàsica de replicació a SQL Server (Always On Availability Groups)

SQL Server agrupa una o més bases de dades dins d'un Availability Group (AG), que es replica de forma síncrona o asíncrona cap a una o més rèpliques secundàries. La gestió del clúster subjacent (detecció de fallades, quòrum) la fa el Windows Server Failover Cluster (WSFC) o Pacemaker a Linux; el detall de configuració del clúster queda fora de l'abast d'aquest mòdul, però cal conèixer el flux a alt nivell:

-- Activar la funcionalitat Always On al servei (requereix reinici)
-- (es fa des de SQL Server Configuration Manager, no per T-SQL)

-- Crear el grup de disponibilitat (des del primari)
CREATE AVAILABILITY GROUP ag_bigdata
    FOR DATABASE bigdata
    REPLICA ON
        'SQLPRIMARI' WITH (
            ENDPOINT_URL = 'TCP://sqlprimari.local:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = AUTOMATIC
        ),
        'SQLREPLICA' WITH (
            ENDPOINT_URL = 'TCP://sqlreplica.local:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = AUTOMATIC
        );

-- Verificar l'estat del grup de disponibilitat
SELECT ag.name, ar.replica_server_name, ars.role_desc, ars.synchronization_health_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ar.group_id = ag.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ars.replica_id = ar.replica_id;

Tecnologies anteriors als Availability Groups

Abans dels AG (introduïts a SQL Server 2012), SQL Server oferia Log Shipping (enviament periòdic i amb retard de còpies del transaction log, encara útil per a escenaris de baix cost o DR amb RPO relaxat) i Database Mirroring (replicació d'una sola base de dades cap a una única rèplica, declarada obsoleta des de SQL Server 2012 en favor dels AG). En sistemes heretats és habitual trobar-les encara en producció.

Configuració bàsica de replicació a Oracle (Data Guard)

Data Guard manté una o més bases de dades standby sincronitzades amb la primària mitjançant el transport del redo log. La creació de l'standby parteix d'una còpia física de la base de dades (normalment amb RMAN) i després s'estableix el flux continu de redo:

# Crear l'standby físic (a alt nivell, requereix backup RMAN previ)
# A la instància standby:
rman target sys/oracle@PRIMARI auxiliary sys/oracle@STANDBY <<EOF
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE;
EOF

-- Configuració bàsica al primari (init.ora / spfile)
ALTER SYSTEM SET log_archive_dest_2='SERVICE=STANDBY ASYNC VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=standby';
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(primari,standby)';

# Amb Data Guard Broker (recomanat, simplifica la gestió)
dgmgrl sys/oracle@primari
DGMGRL> CREATE CONFIGURATION 'dg_bigdata' AS PRIMARY DATABASE IS 'primari' CONNECT IDENTIFIER IS primari;
DGMGRL> ADD DATABASE 'standby' AS CONNECT IDENTIFIER IS standby;
DGMGRL> ENABLE CONFIGURATION;
DGMGRL> SHOW CONFIGURATION;

Data Guard Broker

Configurar Data Guard només amb paràmetres init.ora/spfile és possible però laboriós i propens a errors de sincronització entre primari i standby. El Data Guard Broker (dgmgrl) ofereix una capa de gestió declarativa que simplifica la creació, el monitoratge i el failover/switchover de la configuració, i és la pràctica recomanada en producció.

Replicació síncrona vs asíncrona

Característica	Asíncrona (per defecte)	Síncrona
Latència d'escriptura	No afectada	Augmenta (espera confirmació de la réplica)
Risc de pèrdua de dades	Possible (les últimes transaccions no confirmades a la réplica)	Cap (zero data loss)
Disponibilitat si la réplica cau	Primari continua sense interrupcions	Primari es bloqueja fins que la réplica torna
Cas d'ús	Escalat de lectures, backups	Sistemes financers, requeriments RPO=0

El nom que rep cada mode varia segons el motor:

Motor	Mode asíncron	Mode síncron
PostgreSQL	Replicació streaming per defecte (sense synchronous_standby_names)	Replicació síncrona (synchronous_standby_names)
MySQL/MariaDB	Replicació asíncrona (per defecte)	Semi-synchronous replication (plugin opcional; espera confirmació d'almenys una rèplica abans de confirmar al client, no és síncron 100%)
SQL Server	AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT	AVAILABILITY_MODE = SYNCHRONOUS_COMMIT (configurable per rèplica dins l'AG)
Oracle (Data Guard)	Maximum Performance (per defecte)	Maximum Protection / Maximum Availability (síncron, amb diferent tolerància a fallades)

PostgreSQLMySQL / MariaDBSQL ServerOracle

-- Activar replicació síncrona per a una réplica concreta
-- A postgresql.conf del primari:
-- synchronous_standby_names = 'FIRST 1 (replica1)'

-- Verificar l'estat de sincronisme
SELECT application_name, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;

-- Verificar si el plugin semi-síncron està actiu i el seu estat
SHOW VARIABLES LIKE 'rpl_semi_sync%';

-- Camps clau: rpl_semi_sync_source_enabled, rpl_semi_sync_replica_enabled,
-- rpl_semi_sync_source_timeout (temps d'espera abans de degradar a asíncron)

-- Consultar el mode de sincronització de cada rèplica de l'AG
SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas ar;

-- Consultar el mode de protecció de Data Guard
SELECT protection_mode, protection_level FROM v$database;

-- Canviar el mode de protecció (cal fer-ho amb totes les standby ja configurades)
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

Failover manual i Patroni

Un failover manual promou la réplica a primari amb:

# A la réplica: promou-la a primari
pg_ctl promote -D /var/lib/postgresql/17/main

# O via SQL (PostgreSQL 12+)
SELECT pg_promote();

Per a failover automàtic en producció, l'eina estàndard del sector és Patroni: un daemon que monitoritza la salut del clúster, gestiona el failover automàtic via consens distribuït (etcd, Consul o ZooKeeper) i exposa una API REST per a la gestió. La configuració completa de Patroni queda fora de l'abast d'aquest mòdul, però és important conèixer-ne l'existència com a solució de referència.

Failover a MySQL/MariaDB

El failover manual implica trencar la replicació a la rèplica que es vol promoure i treure-la del mode de només lectura:

-- A la rèplica que es promou a nou primari
RESET REPLICA ALL;
SET GLOBAL read_only = OFF;

-- A la resta de rèpliques: reapuntar-les cap al nou primari
-- CHANGE REPLICATION SOURCE TO SOURCE_HOST = '<nou primari>', ...

Per a failover automàtic, l'eina de referència moderna és MySQL InnoDB Cluster / Group Replication, que aporta consens distribuït integrat (similar en esperit a Patroni). Com a alternativa de tercers, és habitual trobar Orchestrator.

Failover a SQL Server

Amb FAILOVER_MODE = AUTOMATIC configurat a l'Availability Group, el failover el gestiona automàticament el Windows Server Failover Cluster quan detecta que el primari no respon. També es pot forçar manualment:

ALTER AVAILABILITY GROUP ag_bigdata FAILOVER;

Failover a Oracle (Data Guard)

Amb el Data Guard Broker, el failover (promoció d'una standby quan el primari ha caigut, amb possible pèrdua de les últimes transaccions no transmeses) i el switchover (canvi de rol planificat, sense pèrdua de dades) es fan amb una sola comanda:

DGMGRL> FAILOVER TO standby;
DGMGRL> SWITCHOVER TO standby;

Per a failover totalment automàtic, cal activar el Fast-Start Failover (FSFA) del Broker. Una alternativa arquitecturalment diferent és Oracle RAC (Real Application Clusters): no és pròpiament una "rèplica", sinó múltiples instàncies actives simultàniament sobre el mateix emmagatzematge compartit (arquitectura actiu-actiu), pensada més per a escalabilitat i tolerància a fallades de node que per a disposar de còpies separades de les dades.

Monitoratge del lag de replicació

El lag de replicació és el retard entre el moment en què una transacció es confirma al primari i el moment en què la réplica l'ha aplicat. Un lag elevat pot indicar problemes de xarxa, sobrecàrrega de la réplica o transaccions molt grans.

PostgreSQLMySQL / MariaDBSQL ServerOracle

-- Al primari: estat de totes les répliques connectades
SELECT
    application_name,
    client_addr,
    state,
    sync_state,
    pg_size_pretty(pg_wal_lsn_diff(sent_lsn, replay_lsn)) AS lag_bytes,
    now() - reply_time AS lag_temps
FROM pg_stat_replication
ORDER BY lag_bytes DESC;

-- A la réplica: quant de WAL porta de retard
SELECT now() - pg_last_xact_replay_timestamp() AS lag_temps;

SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 0  (al dia)

El camp clau és Seconds_Behind_Source (anomenat Seconds_Behind_Master en versions anteriors a MySQL 8.0.22), que indica quants segons porta de retard el thread SQL/applier respecte al que ha descarregat el thread I/O.

SELECT database_name, synchronization_state_desc,
       log_send_queue_size, redo_queue_size
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.databases d ON d.database_id = drs.database_id;

log_send_queue_size indica el volum de transaction log pendent d'enviar a la rèplica; redo_queue_size, el volum pendent d'aplicar-hi.

SELECT name, value, unit FROM v$dataguard_stats
WHERE name IN ('transport lag', 'apply lag');

La vista V$DATAGUARD_STATS es consulta des de l'standby; V$ARCHIVE_DEST_STATUS es pot consultar des del primari per veure l'estat de transmissió cap a cada destinació d'arxivat.

Alertes de lag

En entorns de producció, configureu alertes (Prometheus + postgres_exporter per a PostgreSQL, mysqld_exporter per a MySQL/MariaDB, o les eines de monitoratge natives de SQL Server/Oracle Enterprise Manager) que disparin quan el lag superi un llindar acceptable (per exemple, 30 segons). Un lag creixent és un senyal d'avís primerenc de problemes, independentment del motor.

Per què cal limitar el nombre de connexions obertes (exemple de PostgreSQL)

El cost de mantenir moltes connexions obertes és un problema comú a tots els SGBD relacionals, encara que cada motor el pateix de manera diferent segons com gestiona internament les connexions. Vegem primer el cas de PostgreSQL, on el problema és especialment visible: cada connexió a PostgreSQL és un procés UNIX independent (no un thread). Cada procés consumeix entre 5 i 10 MB de memòria i té un cost d'inicialització significant. Amb 1000 connexions actives simultànies:

• El sistema operatiu gestiona 1000 processos, augmentant el context switching.
• PostgreSQL necessita 5-10 GB de RAM només per als processos de connexió.
• El planificador de l'SO dedica molt de temps a gestionar processos inactius.

La solució és un connection pool: un procés intermediari que manté un nombre reduït de connexions reals a PostgreSQL i atén molts clients des d'un pool compartit.

I als altres motors?

El problema de fons —el cost de mantenir moltes connexions obertes— no és exclusiu de PostgreSQL, però cada motor el pateix (i el resol) de manera diferent:

• MySQL/MariaDB: cada connexió també consumeix memòria, però es gestiona amb un thread, no amb un procés UNIX complet com a PostgreSQL. És més lleuger, però igualment limitat: amb milers de connexions concurrents, el consum de memòria i el cost de canvi de context entre threads continuen sent un problema real. L'eina de pooling estàndard del sector és ProxySQL, que no és només un pool sinó un proxy intel·ligent capaç d'encaminar lectures cap a rèpliques i escriptures cap al primari. Una alternativa més senzilla, oficial d'Oracle/MySQL, és MySQL Router, pensat sobretot per encaminar trànsit cap a InnoDB Cluster.
• SQL Server: gestiona les connexions com a threads lleugers (tampoc processos UNIX), i els drivers oficials (ADO.NET, JDBC) ja implementen connection pooling al costat client per defecte, de manera transparent per a l'aplicació. Per això, en la majoria de casos no cal cap proxy intermedi equivalent a PgBouncer. Per a control de recursos a nivell de servidor (no de pooling de connexions, sinó de limitació de CPU/memòria per grups de càrrega de treball), SQL Server ofereix el Resource Governor, un concepte diferent però relacionat.
• Oracle: l'equivalent més proper i directe a PgBouncer és DRCP (Database Resident Connection Pooling), introduït a Oracle 11g i especialment pensat per a aplicacions amb moltes connexions curtes (PHP, aplicacions web sense pooling propi). Oracle ofereix també Oracle Connection Manager (CMAN) com a proxy de xarxa i UCP (Universal Connection Pool) com a llibreria de pooling al costat client per a aplicacions Java.

PgBouncer: connection pooling a PostgreSQL

PgBouncer és el pooler de connexions estàndard per a PostgreSQL (no és l'única solució possible: cada motor té les seves pròpies eines, com es veurà a la secció "Connection pooling als altres motors" més avall). Funciona com un proxy: les aplicacions es connecten a PgBouncer (port 6432 per conveni) i PgBouncer manté un pool de connexions reals contra PostgreSQL.

Modes de pooling

Mode	Comportament	Cas d'ús
session	Una connexió de pool per client durant tota la sessió.	Aplicacions que usen variables de sessió o cursors oberts.
transaction	La connexió es retorna al pool entre transaccions.	La majoria d'aplicacions web. El més eficient.
statement	La connexió es retorna al pool entre sentències.	Restringit: incompatible amb transaccions multi-sentència.

Configuració bàsica de PgBouncer amb Docker

# docker-compose.yml
services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: bigdata_joan_puig
    volumes:
      - pgdata:/var/lib/postgresql/data

  pgbouncer:
    image: bitnami/pgbouncer:latest
    ports:
      - "6432:6432"
    environment:
      POSTGRESQL_HOST: postgres
      POSTGRESQL_PORT: 5432
      POSTGRESQL_DATABASE: bigdata_joan_puig
      POSTGRESQL_USERNAME: postgres
      POSTGRESQL_PASSWORD: secret
      PGBOUNCER_POOL_MODE: transaction
      PGBOUNCER_MAX_CLIENT_CONN: 1000
      PGBOUNCER_DEFAULT_POOL_SIZE: 20
    depends_on:
      - postgres

volumes:
  pgdata:

Fitxer pgbouncer.ini (configuració manual sense Docker)

[databases]
bigdata_joan_puig = host=127.0.0.1 port=5432 dbname=bigdata_joan_puig

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3
server_idle_timeout = 600
log_file = /var/log/pgbouncer/pgbouncer.log

# /etc/pgbouncer/userlist.txt
"postgres" "contrasenya_scram_sha256_hash"

Paràmetres clau

• max_client_conn: connexions màximes de clients cap a PgBouncer. Pot ser molt elevat (1000, 5000).
• default_pool_size: connexions reals màximes que PgBouncer manté obertes cap a PostgreSQL per base de dades+usuari. Manteneu-lo per sota del max_connections de PostgreSQL.
• min_pool_size: connexions mínimes pre-obertes per reduir la latència de les primeres connexions.
• reserve_pool_size: connexions addicionals per a pics puntuals.

Monitoratge de PgBouncer

PgBouncer exposa estadístiques via una pseudo-base de dades especial pgbouncer:

-- Connectar-se al port de PgBouncer i consultar la base de dades 'pgbouncer'
-- psql -p 6432 -U postgres pgbouncer

SHOW POOLS;
-- Mostra: base de dades, usuari, cl_active, cl_waiting, sv_active, sv_idle, sv_used

SHOW STATS;
-- Mostra: total_requests, total_received, total_sent, total_query_time

SHOW CLIENTS;
-- Llista de connexions de clients actives

Connection pooling als altres motors

ProxySQL i MySQL Router (MySQL/MariaDB)

ProxySQL és l'eina de pooling i proxy estàndard del sector per a MySQL/MariaDB. A més de mantenir un pool de connexions reals contra el servidor (o servidors) de bases de dades, actua com a proxy intel·ligent: pot encaminar automàticament les lectures cap a rèpliques i les escriptures cap al primari, aplicant regles de partició de trànsit.

proxysql:
  image: proxysql/proxysql:latest
  ports:
    - "6033:6033"  # port de dades (equivalent al 6432 de PgBouncer)
    - "6032:6032"  # port d'administració

Com a alternativa més senzilla, MySQL Router (oficial d'Oracle/MySQL) ofereix encaminament de connexions, pensat sobretot per a topologies amb InnoDB Cluster.

Connection pooling a SQL Server

SQL Server no necessita habitualment un proxy de pooling dedicat com PgBouncer: els drivers oficials (ADO.NET, JDBC) ja implementen pooling al costat client de manera transparent. El control de recursos a nivell de servidor es fa amb el Resource Governor, que limita CPU i memòria per grups de càrrega de treball — un mecanisme de govern de recursos, no de pooling de connexions pròpiament dit.

DRCP, CMAN i UCP (Oracle)

DRCP (Database Resident Connection Pooling), disponible des d'Oracle 11g, és l'equivalent més directe a PgBouncer: un pool de connexions mantingut pel propi servidor de base de dades, pensat per a aplicacions amb moltes connexions curtes (per exemple, aplicacions PHP sense pooling propi).

-- Activar DRCP
EXEC DBMS_CONNECTION_POOL.START_POOL();

-- Connexió de l'aplicació especificant el servei _pooled
-- jdbc:oracle:thin:@//host:1521/orcl:POOLED

Oracle ofereix també Oracle Connection Manager (CMAN), un proxy de xarxa, i UCP (Universal Connection Pool), una llibreria de pooling al costat client per a aplicacions Java.

---

AC5074/02/04 — Miniactivitat

Una aplicació web té les característiques següents: 1000 usuaris registrats, amb un màxim de 200 usuaris concurrents en hora punta, cada usuari fa una petició HTTP cada 3 segons de mitjana, i cada petició executa entre 1 i 3 consultes SQL amb una durada mitjana de 50 ms cadascuna. Calculeu: (a) el nombre de consultes SQL per segon en hora punta; (b) el nombre de connexions simultànies obertes a PostgreSQL sense pooling; (c) el default_pool_size mínim necessari a PgBouncer en mode transaction per a atendre la càrrega; (d) dissenyeu el bloc [pgbouncer] del fitxer de configuració amb els valors justificats. Mostreu el raonament pas a pas.

Opcionalment, si treballeu amb un altre motor, podeu adaptar el raonament a ProxySQL (MySQL/MariaDB) o a DRCP (Oracle), ajustant els paràmetres equivalents de pool.