MySQL, en el servidor origen:

1
2
3
4

mysqldump --databases app -h db.example -u dumper -p \
  --hex-blob --single-transaction --set-gtid-purged=OFF \
  --default-character-set=utf8mb4 --routines --triggers --events \
  | sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' | gzip > app.sql.gz

PostgreSQL, en el servidor origen:

1
2

pg_dump app -h db.example -U dumper --format=plain --no-owner --no-acl \
  | sed -E 's/(DROP|CREATE|COMMENT ON) EXTENSION/-- \1 EXTENSION/g' | gzip > app.sql.gz

Y en los dos casos:

1
2
3
4
5
6
7

SA=$(gcloud sql instances describe my-instance --format='value(serviceAccountEmailAddress)')
gcloud storage buckets add-iam-policy-binding gs://my-dumps \
  --member="serviceAccount:$SA" --role=roles/storage.objectAdmin
gcloud storage cp app.sql.gz gs://my-dumps/

gcloud sql import sql my-instance gs://my-dumps/app.sql.gz --database=app                 # MySQL
gcloud sql import sql my-instance gs://my-dumps/app.sql.gz --database=app --user=postgres  # PostgreSQL

gcloud sql import sql acepta SQL plano o .gz: el formato custom de pg_dump va por pg_restore (abajo).

Los errores y de dónde salen

En Cloud SQL nadie tiene SUPER (MySQL) ni es superusuario (PostgreSQL); el administrador es root@% o postgres, miembro de cloudsqlsuperuser. Todo lo que un dump normal da por hecho de un servidor propio se rompe justo ahí:

MySQL: qué hacer con los DEFINER

Primero mira cuántos y cuáles hay en el origen:

1
2
3
4

SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;

Tres salidas, de más a menos fiel al original:

1. Crear los usuarios en la instancia antes de importar, con el mismo user@host: gcloud sql users create app --host=% --instance=my-instance --password=…. Es lo que recomienda la documentación, y mantiene las vistas y procedimientos exactamente como estaban. root@localhost es la excepción: no se puede crear en Cloud SQL, así que un DEFINER con ese valor hay que cambiarlo sí o sí.
2. Quitar el DEFINER con el sed de arriba: los objetos se crean con el usuario que importa como definer. Suficiente cuando los usuarios del origen no van a existir en Cloud SQL.
3. Pasar a SQL SECURITY INVOKER (sed -E 's/SQL SECURITY DEFINER/SQL SECURITY INVOKER/g' además del anterior): la vista o el procedimiento corre con los privilegios de quien lo llama y el definer deja de importar. Cambia el modelo de permisos; revisa que los usuarios de la aplicación puedan leer las tablas de debajo.

El sed es deliberadamente amplio porque DEFINER= aparece también dentro de comentarios condicionales (/*!50013 DEFINER=… SQL SECURITY DEFINER */); borrar solo el DEFINER= deja el resto intacto y válido.

MySQL: los flags, uno por uno

Si el usuario con el que haces el dump no tiene PROCESS, mysqldump 8.0.21+ falla al inicio con “Access denied; you need (at least one of) the PROCESS privilege(s)” al consultar tablespaces: añade --no-tablespaces.

PostgreSQL: plano o custom

--no-owner --no-acl hacen que todo lo importado pertenezca al --user y no haya GRANT a roles fantasma. Si la aplicación se conecta con otro rol, crea el rol antes y usa --user=app, o reasigna después:

1

REASSIGN OWNED BY postgres TO app;   -- conectado como postgres, en la base importada

Las extensiones que necesite la base (pg_trgm, postgis, uuid-ossp…) créalas antes de importar, como postgres, en la base destino: CREATE EXTENSION IF NOT EXISTS pg_trgm;. Solo funcionan las de la lista de extensiones soportadas de Cloud SQL; plpgsql ya está. Con eso, comentar los CREATE EXTENSION del dump no quita nada.

Si prefieres el formato custom (-Fc), el filtro de extensiones va en la lista de contenidos de pg_restore, tal como lo documenta Google, y restauras a través del Cloud SQL Auth Proxy:

1
2
3

pg_dump app -h db.example -U dumper --format=custom --no-owner --no-acl > app.dmp
pg_restore --list app.dmp | sed -E 's/(.*EXTENSION )/; \1/g' > app.toc
pg_restore --use-list=app.toc --no-owner --no-acl -j 4 -h 127.0.0.1 -U postgres -d app app.dmp

-j 4 restaura en paralelo, cosa que la importación desde el bucket no hace.

Trampas

• El rol del bucket va a la service account de la instancia, no a la tuya: la documentación pide storage.objectAdmin (para importar bastan storage.objects.get y list, es decir, objectViewer). Sin él, “The service account does not have the required permissions for the bucket” aunque tú puedas leer el objeto.
• Una operación a la vez por instancia: si hay un backup o export en marcha, la importación falla con “operation already in progress”. gcloud sql operations list --instance=my-instance lo muestra.
• Dumps grandes: la importación es en serie y tarda; lanza con --async y vigila con gcloud sql operations wait OPERATION_ID --timeout=unlimited, o el gcloud se te muere por el camino.
• Versión de pg_dump: usa la misma versión mayor que el destino o inferior. pg_dump 17 escribe SET transaction_timeout = 0;, que un PostgreSQL 16 rechaza con “unrecognized configuration parameter” y aborta la importación.
• utf8mb4 en la instancia: --default-character-set=utf8mb4 en el dump no arregla una instancia creada con latin1; comprueba character_set_server en los flags de la instancia antes de importar.
• El sed de DEFINER también toca datos: si alguna fila contiene literalmente DEFINER=`x`@`y` (raro, pero un CMS que guarda SQL puede), sáltala con un patrón anclado a CREATE, o revisa el diff del dump.

Ver también

• PostgreSQL: cheat sheet de administración — roles, pg_dump, REASSIGN OWNED y compañía.
• Import and export using SQL dump files (MySQL), DEFINER clause y pg_dump / pg_restore (PostgreSQL) en la documentación de Cloud SQL.

1

GRANT CHANGE NOTIFICATION TO app_user;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

import oracledb

def on_change(message):
    for query in message.queries:
        for table in query.tables:
            for row in table.rows:
                print(table.name, row.operation, row.rowid)

conn = oracledb.connect(user="app_user", password=pw,
                        dsn="db.example:1521/orclpdb1", events=True)

sub = conn.subscribe(callback=on_change,
                     operations=oracledb.OPCODE_INSERT | oracledb.OPCODE_UPDATE | oracledb.OPCODE_DELETE,
                     qos=oracledb.SUBSCR_QOS_QUERY | oracledb.SUBSCR_QOS_ROWIDS)
sub.registerquery("select id, status, updated_at from orders")   # columnas explícitas, nunca SELECT *

input("Ctrl+C para salir\n")

Cada COMMIT que cambie el resultado de esa consulta dispara on_change con los rowid afectados. Sin polling, sin triggers, sin GoldenGate.

Por qué

Cuando otro sistema necesita reaccionar a cambios en Oracle (invalidar una caché, replicar hacia otra base, disparar un proceso), lo habitual es preguntar cada N segundos con WHERE updated_at > :last. Funciona hasta que no: filas sin columna de fecha, borrados que no dejan rastro, carga inútil sobre la base.

Continuous Query Notification invierte el flujo: registras una consulta y Oracle te llama cuando cambia. En modo query (SUBSCR_QOS_QUERY) avisa solo si cambia el resultado de esa consulta; en modo object (sin ese flag) avisa ante cualquier cambio en las tablas implicadas. SUBSCR_QOS_ROWIDS incluye los rowid en la notificación, con lo que el callback puede leer exactamente esas filas.

El caso: replicar Oracle a PostgreSQL

oracle_fdw deja consultar tablas de Oracle desde PostgreSQL como si fueran locales, y es tentador pensar que un trigger sobre la foreign table se disparará cuando cambien los datos en Oracle. No: los triggers de una foreign table solo saltan con escrituras hechas desde PostgreSQL a través de ella. El autor de oracle_fdw lo dice tal cual: no hay forma automática de mantener sincronizada una tabla de PostgreSQL con una de Oracle desde el lado PostgreSQL; eso tiene que dispararlo Oracle.

Con CQN el pequeño servicio en Python es la pieza que falta:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

def on_change(message):
    rowids = [row.rowid for q in message.queries for t in q.tables for row in t.rows]
    with conn.cursor() as cur:
        cur.execute("select id, status, updated_at from orders where rowid in (%s)"
                    % ",".join(f"'{r}'" for r in rowids))
        for id_, status, updated_at in cur:
            pg.execute("insert into orders (id, status, updated_at) values (%s, %s, %s) "
                       "on conflict (id) do update set status = excluded.status, updated_at = excluded.updated_at",
                       (id_, status, updated_at))
    pg.commit()

Los borrados llegan con row.operation & oracledb.OPCODE_DELETE y un rowid que ya no existe: borra en PostgreSQL por la clave que guardaste asociada a ese rowid, o marca la fila.

Requisitos

• Permiso: GRANT CHANGE NOTIFICATION TO app_user, además de SELECT sobre las tablas.
• events=True en la conexión que se suscribe; sin eso subscribe() falla.
• Red de vuelta. Por defecto es la base la que abre una conexión hacia tu aplicación para entregar las notificaciones: la máquina del cliente necesita una IP alcanzable desde el servidor Oracle y un puerto abierto (subscribe(..., ip_address=…, port=…) fija cuáles). Detrás de NAT, en un contenedor o con firewall entre medias, las notificaciones simplemente no llegan y nadie avisa.
• client_initiated=True elimina ese problema: la conexión la abre tu app. Requiere modo Thick (oracledb.init_oracle_client() con Instant Client 19.4 o superior) y base 19.4 o superior. En modo Thin, el por defecto de python-oracledb, CQN funciona pero solo en el modo clásico.
• job_queue_processes mayor que cero en la base: las notificaciones se despachan por el job queue.

Trampas

• ORA-29977: Unsupported column type for query registration in guaranteed mode: en modo query hay tipos de columna que Oracle no admite (LOB, entre otros), y SELECT * los arrastra. Lista las columnas que necesitas o quita SUBSCR_QOS_QUERY y trabaja en modo object.
• Las notificaciones no son durables: si tu servicio está caído durante un cambio, no lo recibe. Al arrancar, haz una reconciliación (por updated_at, o completa) y después suscríbete. timeout=0 en subscribe mantiene la suscripción hasta que la conexión muera.
• Una suscripción por conexión viva: la conexión con events=True tiene que seguir abierta; ponle keepalives y reconecta con re-suscripción si se cae.
• Mucho volumen (miles de commits por segundo) no es territorio de CQN: ahí entra un CDC por redo log (GoldenGate, o Debezium con su conector de Oracle vía LogMiner).
• SELECT con funciones no deterministas o sobre vistas complejas puede no registrarse en modo query; simplifica la consulta o cae a modo object.

Referencia: Continuous Query Notification en la documentación de python-oracledb y la discusión en oracle_fdw.

1
2
3

; /etc/pgbouncer/pgbouncer.ini
[pgbouncer]
ignore_startup_parameters = extra_float_digits, options

1

systemctl reload pgbouncer          # o RELOAD; en la consola de admin: psql -p 6432 -U pgbouncer pgbouncer

extra_float_digits se puede ignorar sin efectos. options (lo que JDBC y DataGrip usan para -c search_path=…) también se ignora, pero entonces el search_path del cliente no llega: fíjalo en el rol con alter role app set search_path = app, public.

El error

1

FATAL: unsupported startup parameter: extra_float_digits

o, según el cliente, pooler error: unsupported startup parameter: extra_float_digits. Directo al puerto 5432 conecta; por el 6432 de pgbouncer, no. Lo mandan JDBC (todo lo que use el driver de PostgreSQL para Java: DBeaver, DataGrip, Spring, Jenkins), Npgsql y algunos ORMs; otros clientes mandan options.

Por qué pasa

Cuando un cliente abre conexión, mete en el paquete de inicio los parámetros de sesión que quiere (extra_float_digits=3, options=-c search_path=app). pgbouncer, en modo transaction o statement, comparte una misma conexión de servidor entre muchos clientes, así que solo deja pasar los parámetros que sabe guardar por cliente y restaurar en el servidor cuando le toca a ese cliente: client_encoding, datestyle, timezone, standard_conforming_strings, application_name. Cualquier otro sería un ajuste que se filtra de un cliente a otro; antes que eso, pgbouncer rechaza la conexión.

Dos formas de resolverlo:

extra_float_digits es inofensivo desde PostgreSQL 12: la salida de float ya es la representación más corta exacta y el parámetro no cambia nada. options con search_path sí importa: ignorado, el cliente verá el search_path por defecto de la base y las consultas sin esquema fallan con relation does not exist. La solución limpia es el rol:

1

alter role app set search_path = app, public;

’no such database'

1

pooler error: no such database: app_db

pgbouncer solo enruta bases que estén en [databases]. O añades la entrada, o pones un comodín:

1
2
3

[databases]
app_db = host=db.example port=5432 dbname=app_db
* = host=db.example port=5432

Con *, un cliente que pida otra_db obtiene host=db.example dbname=otra_db; esas entradas automáticas se limpian solas tras autodb_idle_timeout. Y comprueba el dbname= de la entrada: es habitual apuntar app_db a otra base por un copy-paste.

Trampas

• RELOAD basta para ignore_startup_parameters y [databases]; listen_* y auth_type piden reinicio.
• Modo transaction y SET: un SET search_path a mano en la sesión se pierde en cuanto la conexión de servidor pasa a otro cliente; usa SET LOCAL dentro de la transacción o el alter role.
• Prepared statements con nombre (JDBC prepareThreshold, PREPARE) no funcionan en modo transaction en pgbouncer antiguo; desde 1.21, max_prepared_statements = 200 los soporta.
• SCRAM: con auth_type = scram-sha-256 la userlist.txt necesita el hash SCRAM tal cual sale de pg_authid, o auth_query para que pgbouncer lo consulte.
• SHOW CONFIG; y SHOW DATABASES; en la consola de admin te dicen qué está cargado de verdad, no lo que crees haber escrito.

Ver también: PostgreSQL: cheat sheet de administración. Referencia: pgbouncer.ini.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

-- Filas exactas de todas las tablas de un esquema, en una sola consulta
select table_schema, table_name,
       (xpath('/row/cnt/text()', xml_count))[1]::text::bigint as row_count
from (
  select table_schema, table_name,
         query_to_xml(format('select count(*) as cnt from %I.%I', table_schema, table_name), false, true, '') as xml_count
  from information_schema.tables
  where table_schema = 'public' and table_type = 'BASE TABLE'
) t
order by row_count desc;

-- Estimación instantánea (no lee las tablas)
select relname, n_live_tup from pg_stat_user_tables order by n_live_tup desc;

-- Usuario de solo lectura (PostgreSQL 14 o superior)
create user reporting with password '…';
grant pg_read_all_data to reporting;

Contar filas

count(*) exacto sobre cada tabla exige recorrerla entera; en una base de cientos de GB tarda. Lo que casi siempre quieres es la estimación que mantiene el autovacuum, que se actualiza en cada ANALYZE y suele estar a un par de puntos del real:

1
2
3

select schemaname, relname, n_live_tup, n_dead_tup, last_autoanalyze
from pg_stat_user_tables
order by n_live_tup desc;

Cuando necesitas el número exacto de todas las tablas sin escribir un DO en PL/pgSQL, el truco de query_to_xml: ejecuta un count(*) dinámico por tabla, devuelve el resultado como XML y xpath extrae el número. Es SQL plano, funciona desde cualquier cliente, y se puede filtrar por esquema o por nombre. Solo recuerda que corre los conteos en serie: en tablas grandes, paciencia.

Tamaños

1
2
3
4
5
6
7
8
9

select pg_size_pretty(pg_database_size(current_database()));

select n.nspname as schema, c.relname as table,
       pg_size_pretty(pg_total_relation_size(c.oid)) as total,   -- datos + índices + TOAST
       pg_size_pretty(pg_relation_size(c.oid)) as data
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where c.relkind = 'r' and n.nspname not in ('pg_catalog', 'information_schema')
order by pg_total_relation_size(c.oid) desc
limit 20;

Sesiones

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

-- Quién está conectado y qué hace
select pid, usename, state, client_addr, application_name, left(query, 80) as query
from pg_stat_activity
where datname = current_database();

-- Cancelar una consulta (la sesión sigue)
select pg_cancel_backend(12345);

-- Expulsar a todos menos a ti (antes de un DROP o un restore)
select pg_terminate_backend(pid)
from pg_stat_activity
where datname = 'app_db' and pid <> pg_backend_pid();

-- O, desde PostgreSQL 13, directo:
drop database app_db with (force);

-- Uptime
select date_trunc('second', current_timestamp - pg_postmaster_start_time()) as uptime;

Usuario de solo lectura

En 14 o superior, un rol predefinido lo resuelve para todos los esquemas, incluidas las tablas que se creen mañana:

1
2

create user reporting with password '…';
grant pg_read_all_data to reporting;

En versiones anteriores, o si quieres limitarlo a un esquema, el camino clásico:

1
2
3
4
5
6
7
8
9

grant connect on database app_db to reporting;
grant usage on schema public to reporting;
grant select on all tables in schema public to reporting;
-- tablas futuras: solo cubre las que cree el rol que ejecuta esto (o FOR ROLE app_owner)
alter default privileges for role app_owner in schema public grant select on tables to reporting;

-- Deshacer
revoke all on all tables in schema public from reporting;
alter default privileges for role app_owner in schema public revoke select on tables from reporting;

alter default privileges no toca lo que ya existe y solo aplica a objetos creados por el rol indicado: si otra cuenta crea tablas, reporting no las verá. De ahí el valor de pg_read_all_data.

Contraseñas, timezone y psql

1
2
3
4
5

\password app_user                                  -- desde psql, sin dejar la contraseña en el historial
alter user app_user with password '…';

alter database app_db set timezone to 'America/Mexico_City';   -- nuevas conexiones a esa base
alter role reporting set timezone to 'UTC';                    -- nuevas sesiones de ese rol

1
2

psql -v ON_ERROR_STOP=1 -f data.sql app_db      # un script que se detiene en el primer error
psql -P pager=off app_db                        # sin paginador (o \pset pager 0 dentro)

Y dentro de psql, \x auto (columnas verticales cuando no caben) y \timing.

Mantenimiento mínimo

1
2

vacuum (verbose, analyze) orders;
reindex table concurrently orders;               -- 12+, sin bloquear escrituras

VACUUM FULL reescribe la tabla y la bloquea mientras dura; para recuperar espacio en producción, pg_repack.

Trampas

• n_live_tup es una estimación: recién analizada es fiel; en una tabla con mucho churn puede desviarse hasta el siguiente autoanalyze.
• pg_read_all_data no salta RLS ni concede DDL; es lectura de tablas, vistas y secuencias, nada más.
• pg_terminate_backend corta transacciones: la aplicación ve un error y reconecta. Para solo abortar una consulta, pg_cancel_backend.
• alter role … set timezone aplica a sesiones nuevas; la que ya está abierta sigue igual.
• quote_ident/format('%I') siempre que construyas SQL con nombres de tablas: un nombre con mayúsculas o guiones rompe la consulta sin ellos.

Ver también

• pgbouncer: unsupported startup parameter
• Cloud SQL: importar dumps sin errores de DEFINER, GTID o extensiones