# Uso de extensiones y contenedores de datos externos
Para ampliar la funcionalidad al clúster de bases de datos Aurora PostgreSQL-Compatible Edition puede instalar y utilizar varias *extensiones* de PostgreSQL. Por ejemplo, si su caso de uso requiere entrada intensiva de datos en tablas muy grandes, puede instalar la extensión `[pg\$1partman](https://pgxn.org/dist/pg_partman/doc/pg_partman.html)` para particionar los datos y así difundir la carga de trabajo.
**nota**
A partir de la versión 14.5 de Aurora PostgreSQL, Aurora PostgreSQL admite extensiones de lenguaje de confianza para PostgreSQL. Esta característica se implementa como la extensión `pg_tle`, que puede añadir a su Aurora PostgreSQL. Con esta extensión, los desarrolladores pueden crear sus propias extensiones de PostgreSQL en un entorno seguro que simplifica los requisitos de instalación y configuración, así como gran parte de las pruebas preliminares de las nuevas extensiones. Para obtener más información, consulte [Uso de Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension.md).
En algunos casos, en lugar de instalar una extensión, puede agregar un *módulo* específico a la lista de `shared_preload_libraries` en el grupo de parámetros del clúster de base de datos personalizado del clúster de base de datos de Aurora PostgreSQL. Por lo general, el grupo de parámetros del clúster de base de datos predeterminado solo carga las `pg_stat_statements`, pero hay varios otros módulos disponibles para agregarlos a la lista. Por ejemplo, puede añadir la capacidad de programación añadiendo el módulo`pg_cron`, tal como se detalla en [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](PostgreSQL_pg_cron.md). Como otro ejemplo, puede registrar los planes de ejecución de consultas cargando el módulo `auto_explain`. Para obtener más información, consulte [Logging execution plans of queries](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) (Registro de los planes de ejecución de las consultas) en el centro de conocimiento de AWS.
Una extensión que proporciona acceso a datos externos se conoce específicamente como *contenedor de datos externos*(FDW, por sus siglas en inglés). Por ejemplo, la extensión `oracle_fdw` permite al clúster de bases de datos de Aurora PostgreSQL trabajar con bases de datos Oracle.
También puede especificar con precisión qué extensiones se pueden instalar en la instancia de base de datos de Aurora PostgreSQL, enumerándolas en el parámetro `rds.allowed_extensions`. Para obtener más información, consulte [Restringir la instalación de extensiones de PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction.html).
A continuación, puede encontrar información sobre la configuración y el uso de algunas de las extensiones, módulos y de los FDW disponibles para Aurora PostgreSQL. Para simplificar, todos ellos se denominan “extensiones”. Puede encontrar listas de las extensiones y los FDW que puede usar con las versiones de Aurora PostgreSQL disponibles actualmente, consulte [Versiones de extensión para Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) en las *Notas de versión de Aurora PostgreSQL*.
+ [Administración de objetos grandes con el módulo lo](PostgreSQL_large_objects_lo_extension.md)
+ [Administración de datos espaciales con la extensión PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
+ [Administración de las particiones de PostgreSQL con la extensión pg\$1partman](PostgreSQL_Partitions.md)
+ [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](PostgreSQL_pg_cron.md)
+ [Uso de pgAudit para registrar la actividad de la base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [Uso de pglogical para sincronizar datos entre instancias](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [Uso de una base de datos de Oracle con la extensión oracle\$1fdw](postgresql-oracle-fdw.md)
+ [Uso de bases de datos de SQL Server con la extensión mysql\$1fdw](postgresql-tds-fdw.md)
# Uso de la compatibilidad de extensiones delegadas de Amazon Aurora para PostgreSQL
Al utilizar la compatibilidad de extensiones delegadas de Amazon Aurora para PostgreSQL, puede delegar la administración de la extensión a un usuario que no necesita ser un `rds_superuser`. Con esta compatibilidad de extensiones delegadas, se crea un nuevo rol denominado `rds_extension` que debe asignarse a un usuario para que administre otras extensiones. Este rol puede crear, actualizar y eliminar extensiones.
Puede especificar qué extensiones se pueden instalar en la instancia de base de datos de Aurora PostgreSQL, enumerándolas en el parámetro `rds.allowed_extensions`. Para obtener más información, consulte [Uso de extensiones PostgreSQL con Amazon RDS para PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html).
Puede restringir la lista de extensiones disponibles que el usuario puede administrar con el rol `rds_extension` utilizando el parámetro `rds.allowed_delegated_extensions`.
La compatibilidad de extensiones delegadas está disponible en las siguientes versiones:
+ Todas las versiones superiores
+ Versión 15.5 y versiones posteriores a la 15
+ Versión 14.10 y versiones posteriores a la 14
+ Versión 13.13 y versiones posteriores a la 13
+ Versión 12.17 y versiones posteriores a la 12
**Topics**
+ [Activación de la compatibilidad con extensiones delegadas a un usuario](#AuroraPostgreSQL.delegated_ext_mgmt)
+ [Configuración utilizada en la compatibilidad de extensiones delegadas de Amazon Aurora para PostgreSQL](#AuroraPostgreSQL.delegated_ext_config)
+ [Desactivar la compatibilidad para la extensión delegada](#AuroraPostgreSQL.delegated_ext_disable)
+ [Ventajas del uso de la compatibilidad de extensiones delegadas de Amazon Aurora](#AuroraPostgreSQL.delegated_ext_benefits)
+ [Limitación de la compatibilidad de extensiones delegadas de Aurora para PostgreSQL](#AuroraPostgreSQL.delegated_ext_limit)
+ [Permisos necesarios para determinadas extensiones](#AuroraPostgreSQL.delegated_ext_perm)
+ [Consideraciones de seguridad](#AuroraPostgreSQL.delegated_ext_sec)
+ [Eliminación de extensión en cascada deshabilitada](#AuroraPostgreSQL.delegated_ext_drop)
+ [Ejemplos de extensiones que se pueden agregar mediante la compatibilidad de extensiones delegadas](#AuroraPostgreSQL.delegated_ext_support)
## Activación de la compatibilidad con extensiones delegadas a un usuario
Debe realizar lo siguiente para habilitar la compatibilidad con extensiones delegadas en un usuario:
1. **Otorgar el rol `rds_extension` a un usuario**: conéctese a la base de datos como `rds_superuser` y ejecute el siguiente comando:
```
Postgres => grant rds_extension to user_name;
```
1. **Defina la lista de extensiones disponibles para que las administren los usuarios delegados**: `rds.allowed_delegated_extensions` permite especificar un subconjunto de las extensiones disponibles utilizando `rds.allowed_extensions` en el parámetro del clúster de base de datos. Puede realizar esto en uno de los siguientes niveles:
+ En el clúster o en el grupo de parámetros de la instancia, a través de la Consola de administración de AWS o la API. Para obtener más información, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md).
+ Use el siguiente comando en el nivel de la base de datos:
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Use el siguiente comando en el nivel de usuario:
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**nota**
No es necesario reiniciar la base de datos después de cambiar el parámetro dinámico `rds.allowed_delegated_extensions`.
1. **Permita el acceso del usuario delegado a los objetos creados durante el proceso de creación de la extensión**: algunas extensiones crean objetos que requieren la concesión de permisos adicionales antes de que el usuario con el rol `rds_extension` pueda acceder a ellos. El `rds_superuser` debe conceder al usuario delegado acceso a esos objetos. Una de las opciones es utilizar un desencadenador de eventos para conceder automáticamente el permiso al usuario delegado.
**Ejemplo de desencadenador de eventos**
Si desea permitir que un usuario delegado con `rds_extension` utilice extensiones que requieran configurar permisos en los objetos creados al crear la extensión, puede personalizar el siguiente ejemplo de un desencadenador de eventos y agregar solo las extensiones para las que desee que los usuarios delegados tengan acceso a todas las funciones. Este activador de eventos se puede crear en la plantilla 1 (la plantilla predeterminada), por lo que todas las bases de datos creadas a partir de la plantilla 1 tendrán ese desencadenador de eventos. Cuando un usuario delegado instala la extensión, este desencadenador otorgará automáticamente la propiedad de los objetos creados por la extensión.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Configuración utilizada en la compatibilidad de extensiones delegadas de Amazon Aurora para PostgreSQL
| Nombre de la configuración | Descripción | Valor predeterminado | Notas | Quién puede modificar o conceder el permiso |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | Este parámetro limita las extensiones que un rol de rds\$1extension puede administrar en una base de datos. Debe ser un subconjunto de rds.allowed\$1extensions. | empty string | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/Aurora_delegated_ext.html) Para obtener más información sobre la configuración de este parámetro, consulte [Activación de la compatibilidad con extensiones delegadas a un usuario](#AuroraPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | Este parámetro permite que un cliente limite las extensiones que se pueden instalar en la instancia de base de datos de Aurora PostgreSQL. Para obtener más información, consulte [Restringir la instalación de extensiones de PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction). | "\$1" | De forma predeterminada, este parámetro está establecido en “\$1”, lo que significa que los usuarios con los privilegios necesarios pueden crear todas las extensiones compatibles con RDS para PostgreSQL y Aurora PostgreSQL. Vacío significa que no se pueden instalar extensiones en la instancia de base de datos de Aurora PostgreSQL. | administrator |
| `rds-delegated_extension_allow_drop_cascade` | Este parámetro controla la capacidad del usuario con `rds_extension` de eliminar la extensión mediante una opción en cascada. | apagar | De forma predeterminada, `rds-delegated_extension_allow_drop_cascade` está establecido en `off`. Esto significa que los usuarios con `rds_extension` no pueden eliminar una extensión mediante la opción en cascada. Para otorgar esa habilidad, el parámetro `rds.delegated_extension_allow_drop_cascade` debe configurarse como `on`. | rds\$1superuser |
## Desactivar la compatibilidad para la extensión delegada
**Desactivación parcial**
Los usuarios delegados no pueden crear nuevas extensiones, pero sí pueden actualizar las existentes.
+ Restablece `rds.allowed_delegated_extensions` al valor predeterminado en el grupo de parámetros del clúster de base de datos.
+ Use el siguiente comando en el nivel de la base de datos:
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Use el siguiente comando en el nivel de usuario:
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Desactivación completa**
Al revocar el rol `rds_extension` de un usuario, el usuario recuperará los permisos estándar. El usuario ya no puede crear, actualizar ni eliminar extensiones.
```
postgres => revoke rds_extension from user_name;
```
## Ventajas del uso de la compatibilidad de extensiones delegadas de Amazon Aurora
Al utilizar la compatibilidad de extensiones delegadas de Amazon Aurora para PostgreSQL, delega de forma segura la administración de la extensión a los usuarios que no tengan el rol `rds_superuser`. Esta característica proporciona los siguientes beneficios:
+ Puede delegar fácilmente la administración de extensiones a los usuarios de su elección.
+ Esto no requiere el rol `rds_superuser`.
+ Ofrece la posibilidad de admitir diferentes conjuntos de extensiones para diferentes bases de datos en el mismo clúster de base de datos.
## Limitación de la compatibilidad de extensiones delegadas de Aurora para PostgreSQL
+ Los objetos creados durante el proceso de creación de la extensión pueden requerir privilegios adicionales para que la extensión funcione correctamente.
## Permisos necesarios para determinadas extensiones
Para crear, usar o actualizar las siguientes extensiones, el usuario delegado debe tener los privilegios necesarios en las siguientes funciones, tablas y esquemas.
| Extensiones que necesitan propiedad o permisos | Función | Tablas | Esquema | Diccionario de búsqueda de texto | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | | | |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | | | | |
| dict\$1int | | | | intdict | |
| pg\$1partman | | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | | | |
| pg\$1stat\$1statements | | | | | |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | | | |
| postgis\$1raster | | | | | |
| postgis\$1topology | | topology, layer | topology | | el usuario delegado debe ser el propietario de la base de datos |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | | | | |
| rds\$1tools | role\$1password\$1encryption\$1type | | | | |
| postgis\$1tiger\$1geocoder | | geocode\$1settings\$1default, geocode\$1settings | tiger | | |
| pg\$1freespacemap | pg\$1freespace | | | | |
| pg\$1visibility | pg\$1visibility | | | | |
## Consideraciones de seguridad
Tenga en cuenta que un usuario con el rol `rds_extension` podrá administrar las extensiones en todas las bases de datos en las que tenga el privilegio de conexión. Si la intención es que un usuario delegado administre la extensión en una única base de datos, una práctica recomendada consiste en revocar todos los privilegios del público en cada base de datos y, a continuación, conceder de forma explícita el privilegio de conexión para esa base de datos específica al usuario delegado.
Existen varias extensiones que permiten a un usuario acceder a la información de varias bases de datos. Asegúrese de que los usuarios a los que conceda `rds_extension` tengan capacidades para múltiples bases de datos antes de agregar estas extensiones a `rds.allowed_delegated_extensions`. Por ejemplo, `postgres_fdw` y `dblink` proporcionan la funcionalidad de realizar consultas en todas las bases de datos de la misma instancia o de instancias remotas. `log_fdw` lee los archivos de registro del motor postgres, que son de todas las bases de datos de la instancia, y pueden contener consultas lentas o mensajes de error de varias bases de datos. `pg_cron` permite ejecutar trabajos en segundo plano programados en la instancia de base de datos y puede configurar los trabajos para que se ejecuten en una base de datos diferente.
## Eliminación de extensión en cascada deshabilitada
La posibilidad de eliminar la extensión con la opción en cascada por parte de un usuario con el rol `rds_extension` la controla el parámetro `rds.delegated_extension_allow_drop_cascade`. De forma predeterminada, `rds-delegated_extension_allow_drop_cascade` está establecido en `off`. Esto significa que los usuarios con el tol `rds_extension` no pueden eliminar una extensión mediante la opción en cascada como se muestra en la siguiente consulta.
```
DROP EXTENSION CASCADE;
```
Esto eliminará automáticamente los objetos que dependan de la extensión y, a su vez, todos los objetos que dependan de esos objetos. El intento de utilizar la opción en cascada generará un error.
Para otorgar esa habilidad, el parámetro `rds.delegated_extension_allow_drop_cascade` debe configurarse como `on`.
Cambiar el parámetro dinámico `rds.delegated_extension_allow_drop_cascade` no requiere un reinicio de la base de datos. Puede realizar esto en uno de los siguientes niveles:
+ En el clúster o en el grupo de parámetros de la instancia, a través de la Consola de administración de AWS o la API.
+ Con el siguiente comando en el nivel de la base de datos:
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ Con el siguiente comando en el nivel de usuario:
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Ejemplos de extensiones que se pueden agregar mediante la compatibilidad de extensiones delegadas
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Administración de objetos grandes con el módulo lo
El módulo lo (extensión) es para usuarios de base de datos y desarrolladores que trabajan con bases de datos PostgreSQL mediante controladores JDBC u ODBC. Tanto JDBC como ODBC esperan que la base de datos se encargue de eliminar los objetos grandes cuando cambian las referencias a ellos. No obstante, PostgreSQL no funciona así. PostgreSQL no asume que un objeto se deba eliminar cuando cambie su referencia. El resultado es que los objetos permanecen en el disco, sin referencia. La extensión lo incluye una función que se utiliza para desencadenarse en los cambios de referencia con el fin de eliminar objetos si es necesario.
**sugerencia**
Para determinar si su base de datos se puede beneficiar de la extensión lo, utilice la utilidad `vacuumlo` para comprobar si hay objetos grandes huérfanos. Para obtener el recuento de los objetos grandes huérfanos sin realizar ninguna acción, ejecute la utilidad con la opción `-n` (sin operación). Para saber cómo, consulte [vacuumlo utility](#vacuumlo-utility) a continuación.
El módulo lo está disponible para Aurora PostgreSQL 13.7, 12.11, 11.16, 10.21 y versiones secundarias posteriores.
Para instalar el módulo (extensión), necesita privilegios de `rds_superuser`. La instalación de la extensión lo agrega a su base de datos:
+ `lo`: es un tipo de datos de objeto grande (lo) que puede utilizar para objetos binarios grandes (BLOB) y otros objetos de gran tamaño. El tipo de datos `lo` es un dominio del tipo de datos `oid`. Es decir, se trata de un identificador de objeto con restricciones opcionales. Para obtener más información, consulte [Object identifiers](https://www.postgresql.org/docs/14/datatype-oid.html) (Identificadores de objetos) en la documentación de PostgreSQL. Dicho de forma sencilla, puede utilizar el tipo de datos `lo` para distinguir las columnas de base de datos que contienen referencias a objetos grandes de otros identificadores de objetos (OID).
+ `lo_manage`: es una función que puede utilizar en los desencadenadores de las columnas de tabla que contienen referencias a objetos grandes. Siempre que elimine o modifique un valor que haga referencia a un objeto grande, el desencadenador desvincula el objeto (`lo_unlink`) de su referencia. Utilice el desencadenador en una columna solo si esta es la única referencia de base de datos al objeto grande.
Para obtener más información sobre el módulo de objetos grandes, consulte [lo](https://www.postgresql.org/docs/current/lo.html) en la documentación de PostgreSQL.
## Instalación de la extensión lo
Antes de instalar la extensión lo, asegúrese de que dispone de privilegios de `rds_superuser`.
**Para instalar la extensión lo**
1. Use `psql` para conectarse a la instancia de base de datos principal de su clúster de base de datos de Aurora PostgreSQL.
```
psql --host=your-cluster-instance-1.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Escriba la contraseña cuando se le solicite. El cliente `psql` se conecta y muestra la base de datos de conexión administrativa predeterminada, `postgres=>`, como el símbolo del sistema.
1. Instale la extensión de la siguiente manera:
```
postgres=> CREATE EXTENSION lo;
CREATE EXTENSION
```
Ahora puede utilizar el tipo de datos `lo` para definir columnas en las tablas. Por ejemplo, puede crear una tabla (`images`) que contenga datos de imágenes rasterizadas. Puede utilizar el tipo de datos `lo` para una columna `raster`, como se muestra en el siguiente ejemplo, que crea una tabla.
```
postgres=> CREATE TABLE images (image_name text, raster lo);
```
## Uso de la función de desencadenador lo\$1manage para eliminar objetos
Puede utilizar la función `lo_manage` en un desencadenador en `lo` o en otras columnas de objetos grandes para limpiar (y evitar los objetos huérfanos) cuando `lo` se actualiza o se elimina.
**Para configurar desencadenadores en columnas que hacen referencia a objetos grandes**
+ Realice una de las siguientes acciones:
+ Cree un desencadenador BEFORE UPDATE OR DELETE en cada columna para que contenga referencias únicas a objetos grandes, con el nombre de columna como argumento.
```
postgres=> CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON images
FOR EACH ROW EXECUTE FUNCTION lo_manage(raster);
```
+ Aplique un desencadenador solo cuando la columna se esté actualizando.
```
postgres=> CREATE TRIGGER t_raster BEFORE UPDATE OF images
FOR EACH ROW EXECUTE FUNCTION lo_manage(raster);
```
La función de desencadenador `lo_manage` solo funciona en el contexto de la inserción o eliminación de datos de columna, en función de cómo se defina el desencadenador. No tiene ningún efecto cuando se realiza una operación `DROP` o `TRUNCATE` en una base de datos. Esto significa que debe eliminar las columnas de objeto de cualquier tabla antes de suprimirla, para evitar que se creen objetos huérfanos.
Por ejemplo, suponga que desea eliminar la base de datos que contiene la tabla `images`. Elimina la columna de la siguiente manera.
```
postgres=> DELETE FROM images COLUMN raster
```
Si se supone que la función `lo_manage` está definida en esa columna para gestionar las eliminaciones, ahora puede eliminar la tabla con seguridad.
## Eliminación de objetos grandes huérfanos mediante `vacuumlo`
La utilidad `vacuumlo` identifica y puede eliminar los objetos grandes huérfanos de las bases de datos. Esta utilidad está disponible desde PostgreSQL 9.1.24. Si los usuarios de la base de datos trabajan habitualmente con objetos grandes, le recomendamos que ejecute `vacuumlo` de vez en cuando para limpiar los objetos grandes huérfanos.
Antes de instalar la extensión lo, puede utilizar `vacuumlo` para evaluar si se puede beneficiar su clúster de bases de datos Aurora PostgreSQL. Para ello, ejecute `vacuumlo` con la opción `-n` (sin operación) para mostrar lo que se eliminaría, como se presenta a continuación:
```
$ vacuumlo -v -n -h your-cluster-instance-1.666666666666.aws-region.rds.amazonaws.com -p 5433 -U postgres docs-lab-spatial-db
Password:*****
Connected to database "docs-lab-spatial-db"
Test run: no large objects will be removed!
Would remove 0 large objects from database "docs-lab-spatial-db".
```
Como muestra la salida, los objetos grandes huérfanos no son un problema para esta base de datos concreta.
Para obtener más información sobre esta utilidad, consulte [https://www.postgresql.org/docs/current/vacuumlo.html](https://www.postgresql.org/docs/current/vacuumlo.html) en la documentación de PostgreSQL.
## Funcionamiento de `vacuumlo`
El comando `vacuumlo` elimina los objetos grandes (LO) huérfanos de la base de datos de PostgreSQL sin que ello afecte ni entre en conflicto con las tablas de usuario.
El comando funciona así:
1. `vacuumlo` comienza creando una tabla temporal que contiene todos los ID de objeto (OID) de los objetos grandes de la base de datos.
1. A continuación, `vacuumlo` escanea todas las columnas de la base de datos que utilizan los tipos de datos `oid` o `lo`. Si `vacuumlo` encuentra un OID coincidente en estas columnas, lo elimina de la tabla temporal. `vacuumlo`comprueba solo y específicamente las columnas con los nombres `oid` o `lo`, no los dominios basados en estos tipos.
1. El resto de las entradas de la tabla temporal representan LO huérfanos, que posteriormente elimina `vacuumlo` de forma segura.
## Mejora en el rendimiento de `vacuumlo`
Puede mejorar el rendimiento de `vacuumlo` aumentando el tamaño del lote mediante la opción `-l`. Esto permite a `vacuumlo` procesar más LO a la vez.
Si el sistema tiene memoria suficiente y puede alojar la tabla temporal completamente en la memoria, aumentar la configuración de `temp_buffers` para la base de datos puede mejorar el rendimiento. Esto permite que la tabla resida completamente en la memoria, lo que puede mejorar el rendimiento general.
La siguiente consulta estima el tamaño de la tabla temporal:
```
SELECT
pg_size_pretty(SUM(pg_column_size(oid))) estimated_lo_temp_table_size
FROM
pg_largeobject_metadata;
```
## Consideraciones para objetos grandes
A continuación, encontrará algunas consideraciones importantes que debe tener en cuenta al trabajar con objetos grandes:
+ `Vacuumlo` es la única solución, ya que actualmente no existe otro método para eliminar los LO huérfanos.
+ Las herramientas como pglogical, la replicación lógica nativa y AWS DMS, que utilizan tecnologías de replicación, no admiten la replicación de objetos de gran tamaño.
+ Al diseñar el esquema de la base de datos, evite utilizar objetos grandes siempre que sea posible y, en su lugar, considere la posibilidad de utilizar tipos de datos alternativos como `bytea`.
+ Ejecute `vacuumlo` con regularidad, al menos una vez por semana, para evitar problemas con los LO huérfanos.
+ Utilice un activador con la función `lo_manage` en las tablas que almacenen objetos grandes para evitar que se creen LO huérfanos.
# Administración de datos espaciales con la extensión PostGIS
PostGIS es una extensión de PostgreSQL para almacenar y administrar información espacial. Para obtener más información sobre PostGIS, consulte [PostGIS.net](https://postgis.net/).
A partir de la versión 10.5, PostgreSQL admite la biblioteca libprotobuf 1.3.0 utilizada por PostGIS para trabajar con datos de teselas vectoriales de Mapbox.
La configuración de la extensión PostGIS requiere privilegios de `rds_superuser`. Le recomendamos que cree un usuario (rol) para administrar instalar la extensión PostGIS y los datos espaciales. La extensión PostGIS y sus componentes relacionados añaden miles de funciones a PostgreSQL. Considere la posibilidad de crear la extensión PostGIS en su propio esquema si eso tiene sentido para su caso de uso. En el ejemplo siguiente, se muestra cómo instalar la extensión en su propia base de datos, pero esto no es obligatorio.
**Topics**
+ [Paso 1: cree un usuario (rol) para administrar la extensión PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [Paso 2: cargue las extensiones PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [Paso 3: transferir la propiedad de los esquemas de extensión](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [Paso 4: transferir la propiedad de las tablas de PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [Paso 5: pruebe las extensiones](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [Paso 6: Actualice la extensión de PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [Versiones de extensión de PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Actualización de PostGIS 2 a PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Paso 1: cree un usuario (rol) para administrar la extensión PostGIS
En primer lugar, conéctese a una instancia de base de datos de RDS para PostgreSQL como usuario con privilegios `rds_superuser`. Si mantuvo el nombre predeterminado al configurar la instancia, conéctese como `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Cree un rol independiente (usuario) para administrar la extensión PostGIS.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Conceda los privilegios `rds_superuser` de este rol para permitir que el rol instale la extensión.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Cree una base de datos para utilizarla para sus artefactos de PostGIS. Este paso es opcional. O puede crear un esquema en la base de datos de usuarios para las extensiones de PostGIS, pero esto tampoco es obligatorio.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Conceda todos los privilegios `gis_admin` en la base de datos `lab_gis`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Salga de la sesión y vuelva a conectarse a una instancia de base de datos de RDS para PostgreSQL como `gis_admin`.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Continúe configurando la extensión tal y como se detalla en los pasos siguientes.
## Paso 2: cargue las extensiones PostGIS
La extensión de PostGIS incluye varias extensiones relacionadas que funcionan juntas para proporcionar funcionalidad geoespacial. Dependiendo de su caso de uso, es posible que no necesite todas las extensiones creadas en este paso.
Utilice instrucciones `CREATE EXTENSION` para cargar las extensiones de PostGIS.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
Para verificar los resultados, puede ejecutar la consulta SQL que se muestra en el siguiente ejemplo, que enumera las extensiones y sus propietarios.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Paso 3: transferir la propiedad de los esquemas de extensión
Use las declaraciones de ALTER SCHEMA para transferir la propiedad de los esquemas al rol `gis_admin`.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
Si desea confirmar el cambio de propiedad, ejecute la siguiente consulta SQL. O bien, puede utilizar el metacomando `\dn` de la línea de comandos psql.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Paso 4: transferir la propiedad de las tablas de PostGIS
**nota**
No cambie la propiedad de las funciones de PostGIS. Para que PostGIS funcione correctamente y reciba actualizaciones, estas funciones deben retener la propiedad original. Para obtener más información sobre los permisos de PostGIS, consulte [PostgreSQL Security](https://postgis.net/workshops/postgis-intro/security.html).
Use la siguiente función para transferir la propiedad de las tablas de PostGIS al rol `gis_admin`. Ejecute la siguiente declaración desde el símbolo del sistema psql para crear la función.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
A continuación, ejecute la siguiente consulta para ejecutar la función `exec` que, a su vez, ejecuta las instrucciones y altera los permisos.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Paso 5: pruebe las extensiones
Para evitar tener que especificar el nombre del esquema, añada el esquema `tiger` a la ruta de búsqueda usando el siguiente comando.
```
SET search_path=public,tiger;
SET
```
Pruebe el esquema `tiger` usando la siguiente instrucción SELECT.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
Para obtener más información sobre esta extensión, consulte [Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder) en la documentación de PostGIS.
Pruebe el acceso al esquema `topology` usando la siguiente instrucción `SELECT`. Esto llama a la función `createtopology` para registrar un nuevo objeto de topología (my\$1new\$1topo) con el identificador de referencia espacial especificado (26986) y la tolerancia predeterminada (0,5). Para obtener más información, visite [CreateTopology](https://postgis.net/docs/CreateTopology.html) en la documentación de PostgreSQL.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Paso 6: Actualice la extensión de PostGIS
Cada nueva versión de PostgreSQL admite una o más versiones de la extensión de PostGIS compatibles con esa versión. La actualización del motor de PostgreSQL a una nueva versión no actualiza automáticamente la extensión de PostGIS. Antes de actualizar el motor de PostgreSQL, normalmente se actualiza PostGIS a la versión más reciente disponible para la versión actual de PostgreSQL. Para obtener más información, consulte [Versiones de extensión PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS).
Después de actualizar el motor de PostgreSQL, vuelva a actualizar la extensión de PostGIS a la versión compatible con la versión del motor de PostgreSQL recién actualizada. Para obtener más información sobre la actualización del motor PostgreSQL, consulte [Prueba de la actualización del clúster de base de datos de producción a una nueva versión principal](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
Puede comprobar si hay disponibles actualizaciones de la versión de la extensión PostGIS en su clúster de base de datos de Aurora PostgreSQL en cualquier momento. Para ello, ejecute el siguiente comando. Esta función está disponible con PostGIS 2.5.0 y versiones posteriores.
```
SELECT postGIS_extensions_upgrade();
```
Si su aplicación no es compatible con la última versión de PostGIS, puede instalar una versión anterior de PostGIS que esté disponible en su versión principal de la siguiente manera.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
Si desea actualizar a una versión específica de PostGIS desde una versión anterior, también puede utilizar el siguiente comando.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Dependiendo de la versión desde la que se actualice, es posible que tenga que volver a utilizar esta función. El resultado de la primera ejecución de la función determina si se necesita una función de actualización adicional. Por ejemplo, eso es lo que ocurre para la actualización de PostGIS 2 a PostGIS 3. Para obtener más información, consulte [Actualización de PostGIS 2 a PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
Si actualizó esta extensión para prepararse para una actualización de la versión principal del motor de PostgreSQL, puede continuar con otras tareas preliminares. Para obtener más información, consulte [Prueba de la actualización del clúster de base de datos de producción a una nueva versión principal](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
## Versiones de extensión PostGIS
Le recomendamos que instale las versiones de todas las extensiones, como PostGIS, como se indica en [Versiones de extensión para Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) en las *Notas de la versión de Aurora PostgreSQL*. Para obtener una lista de las versiones que están disponibles en su versión, utilice el siguiente comando.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
Puede encontrar información sobre la versión en las siguientes secciones de las *Notas de la versión de Amazon RDS para PostgreSQL*:
+ [Versiones de extensión para Aurora PostgreSQL 14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.14)
+ [Versiones de extensión para Aurora PostgreSQL-Compatible Edition 13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.13)
+ [Versiones de extensión para Aurora PostgreSQL-Compatible Edition 12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.12)
+ [Versiones de extensión para Aurora PostgreSQL-Compatible Edition 11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.11)
+ [Versiones de extensión para Aurora PostgreSQL-Compatible Edition 10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.10)
+ [Versiones de extensión para Aurora PostgreSQL-Compatible Edition 9.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.96)
## Actualización de PostGIS 2 a PostGIS 3
A partir de la versión 3.0, la funcionalidad de trama de PostGIS es una extensión separada, `postgis_raster`. Esta extensión tiene su propia ruta de instalación y actualización. Esto elimina del núcleo docenas de funciones, tipos de datos y otros artefactos necesarios para el procesamiento de imágenes de trama desde la extensión `postgis` principal. Esto significa que si su caso de uso no requiere procesamiento de tramas, no es necesario que instale la extensión `postgis_raster`.
En el siguiente ejemplo de actualización, el primer comando de actualización extrae la funcionalidad de trama en la extensión `postgis_raster`. Luego, se requiere un segundo comando de actualización para actualizar `postgis_raster` a la nueva versión.
**Para actualizar de PostGIS 2 a PostGIS 3**
1. Identifique la versión predeterminada de PostGIS que está disponible para la versión de PostgreSQL en su clúster de base de datos de Aurora PostgreSQL Para ello, ejecute la siguiente consulta.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identifique las versiones de PostGIS instaladas en cada base de datos en la instancia de escritura del clúster de base de datos de Aurora PostgreSQL. En otras palabras, consulte la base de datos de cada usuario de la siguiente manera.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
Esta falta de correspondencia entre la versión predeterminada (PostGIS 3.1.4) y la versión instalada (PostGIS 2.3.7) significa que debe actualizar la extensión de PostGIS.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Ejecute la siguiente consulta para comprobar que la funcionalidad ráster ahora está en su propio paquete.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
El resultado muestra que aún hay una diferencia entre las versiones. Las funciones de PostGIS son de la versión 3 (postgis-3), mientras que las funciones ráster (rtpostgis) son de la versión 2 (rtpostgis-2.3). Para completar la actualización, vuelva a ejecutar el comando de actualización, como se indica a continuación.
```
postgres=> SELECT postgis_extensions_upgrade();
```
Puede ignorar los mensajes de advertencia sin problemas. Vuelva a ejecutar la siguiente consulta para comprobar que la actualización se ha completado. La actualización se completa cuando en PostGIS y en todas las extensiones relacionadas deja de aparecer una marca que indica que deben actualizarse.
```
SELECT postgis_full_version();
```
1. Utilice la siguiente consulta para ver el proceso de actualización completado y las extensiones empaquetadas por separado, y compruebe que las versiones coinciden.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
El resultado muestra que la extensión de PostGIS 2 se ha actualizado a PostGIS 3 y que ambas, `postgis`y la extensión `postgis_raster` ya separada, son de la versión 3.1.5.
Una vez completada esta actualización, si no tiene pensado usar la funcionalidad de trama, puede eliminar la extensión de la siguiente manera.
```
DROP EXTENSION postgis_raster;
```
# Administración de las particiones de PostgreSQL con la extensión pg\$1partman
Las particiones de tablas de PostgreSQL proporcionan un marco para el manejo de alto rendimiento de la entrada de datos y la generación de informes. Utilice particiones para bases de datos que requieren una entrada muy rápida de grandes cantidades de datos. Las particiones también proporcionan consultas más rápidas de tablas grandes. Las particiones ayudan a mantener los datos sin afectar la instancia de base de datos porque requiere menos recursos de E/S.
Mediante el uso de particiones, puede dividir los datos en fragmentos de tamaño personalizado para su procesamiento. Por ejemplo, puede dividir datos de series temporales para rangos como por hora, por día, por semana, por mes, por trimestre, por año, personalizados o cualquier combinación de estos. Para un ejemplo de datos de series temporales, si divide la tabla por hora, cada partición contiene una hora de datos. Si divide la tabla de series temporales por día, las particiones contienen datos de un día, y así sucesivamente. La clave de partición controla el tamaño de una partición.
Cuando se utiliza un comando `INSERT` o `UPDATE` de SQL en una tabla particionada, el motor de base de datos enruta los datos a la partición adecuada. Las particiones de tablas de PostgreSQL que almacenan los datos son tablas secundarias de la tabla principal.
Durante las lecturas de consultas de la base de datos, el optimizador de PostgreSQL analiza la cláusula `WHERE` de la consulta y, si es posible, dirige el análisis de la base de datos solo a las particiones relevantes.
A partir de la versión 10, PostgreSQL utiliza particiones declarativas para implementar particiones de tablas. Esto también se conoce como particionado PostgreSQL nativo. Antes de PostgreSQL versión 10, usaba desencadenadores para implementar particiones.
Las particiones de tablas de PostgreSQL proporcionan las siguientes características:
+ Creación de nuevas particiones en cualquier momento.
+ Rangos de particiones variables.
+ Particiones desmontables y reconectables mediante instrucciones de lenguaje de definición de datos (DDL).
Por ejemplo, las particiones desmontables son útiles para eliminar datos históricos de la partición principal, pero mantienen los datos históricos para su análisis.
+ Las nuevas particiones heredan las propiedades de la tabla de base de datos principal, incluidas las siguientes:
+ Índices
+ Claves principales, que deben incluir la columna de la clave de partición
+ Claves externas
+ Restricciones de comprobación
+ Referencias
+ creación de índices para la tabla completa o cada partición específica
No se puede modificar el esquema de una partición individual. Sin embargo, se puede modificar la tabla principal (como agregar una nueva columna), que se propaga a las particiones.
**Topics**
+ [Información general de la extensión pg\$1partman de PostgreSQL](#PostgreSQL_Partitions.pg_partman)
+ [Habilitación de la extensión pg\$1partman](#PostgreSQL_Partitions.enable)
+ [Configuración de particiones mediante la función create\$1parent](#PostgreSQL_Partitions.create_parent)
+ [Configuración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc](#PostgreSQL_Partitions.run_maintenance_proc)
## Información general de la extensión pg\$1partman de PostgreSQL
Puede utilizar la extensión `pg_partman` de PostgreSQL para automatizar la creación y el mantenimiento de las particiones de tablas. Para obtener más información general, consulte [PG Partition Manager](https://github.com/pgpartman/pg_partman) en la documentación de `pg_partman`.
**nota**
La extensión `pg_partman` es compatible con las versiones 12.6 y posteriores de Aurora PostgreSQL.
En lugar de tener que crear manualmente cada partición, configure `pg_partman` con las siguientes opciones:
+ Tabla que se dividirá
+ Tipo de partición
+ Clave de partición
+ Grado de detalle de la partición
+ Opciones de precreación y administración de particiones
Después de crear una tabla con particiones de PostgreSQL, la registra con `pg_partman` al llamar a la función `create_parent`. Al hacerlo, se crean las particiones necesarias en función de los parámetros que pase a la función.
La extensión `pg_partman` también proporciona la función `run_maintenance_proc`, que puede ejecutarse de forma programada para administrar automáticamente las particiones. Para asegurarse de que se creen las particiones apropiadas según sea necesario, programe esta función para que se ejecute periódicamente (por ejemplo, por hora). También puede asegurarse de que las particiones se eliminen automáticamente.
## Habilitación de la extensión pg\$1partman
Si tiene varias bases de datos dentro de la misma instancia de base de dato de PostgreSQL para la que desea administrar particiones, debe habilitar la extensión `pg_partman` por separado para cada base de datos. Para habilitar la extensión `pg_partman` para una base de datos específica, cree el esquema de mantenimiento de particiones y, después, cree la extensión `pg_partman` de la siguiente manera:
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**nota**
Para crear la extensión `pg_partman`, asegúrese de tener privilegios `rds_superuser`.
Si recibe un error como el siguiente, conceda los privilegios `rds_superuser` a la cuenta o utilice su cuenta de superusuario.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
Para conceder privilegios `rds_superuser`, conéctese con su cuenta de superusuario y ejecute el siguiente comando:
```
GRANT rds_superuser TO user-or-role;
```
Para los ejemplos que muestran el uso de la extensión pg\$1partman, utilizamos la siguiente tabla de base de datos y partición de muestra. Esta base de datos utiliza una tabla particionada basada en una marca temporal. Un esquema `data_mart` contiene una tabla denominada `events` con una columna denominada `created_at`. En la `events` tabla se incluyen los siguientes ajustes:
+ Claves primarias `event_id` y `created_at`, que deben tener la columna utilizada para guiar la partición.
+ Una restricción de comprobación `ck_valid_operation` para aplicar los valores para una columna de la tabla `operation`.
+ Dos claves externas, donde una (`fk_orga_membership)` apunta a la tabla externa `organization` y la otra (`fk_parent_event_id`) es una clave externa con referencia propia.
+ Dos índices, donde uno (`idx_org_id`) es para la clave externa y el otro (`idx_event_type`) es para el tipo de evento.
Las siguientes instrucciones DDL crean estos objetos, que se incluyen automáticamente en cada partición.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Configuración de particiones mediante la función create\$1parent
Después de habilitar la extensión `pg_partman`, utilice la función `create_parent` para configurar las particiones dentro del esquema de mantenimiento de particiones. En este ejemplo se utiliza el ejemplo de la tabla `events` creado en [Habilitación de la extensión pg\$1partmanConfiguración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable). Ejecute la función `create_parent` de la siguiente manera:
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
Los parámetros son los siguientes:
+ `p_parent_table` – La tabla principal particionada. Esta tabla ya debe existir y estar totalmente cualificada, incluido el esquema.
+ `p_control` – La columna en la que se basará la partición. El tipo de datos debe ser entero o basado en el tiempo.
+ `p_type`: el tipo es `'range'` o `'list'`.
+ `p_interval` – El intervalo de tiempo o intervalo de enteros para cada partición. Los valores de ejemplo incluyen `1 day`, `1 hour`, etc.
+ `p_premake` – La cantidad de particiones que se debe crear de antemano para admitir nuevas inserciones.
Para obtener una descripción completa de la función `create_parent`, consulte [Funciones de creación](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions) en la documentación de `pg_partman`.
## Configuración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc
Puede ejecutar operaciones de mantenimiento de particiones para crear automáticamente nuevas particiones, desasociar particiones o eliminar particiones antiguas. El mantenimiento de particiones se basa en la función `run_maintenance_proc` de la extensión `pg_partman` y la extensión `pg_cron`, que inicia un programador interno. El programador `pg_cron` ejecuta automáticamente instrucciones SQL, funciones y procedimientos definidos en las bases de datos.
En el ejemplo siguiente se utiliza el ejemplo de la tabla `events` creado en [Habilitación de la extensión pg\$1partmanConfiguración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable) para establecer que las operaciones de mantenimiento de particiones se ejecuten automáticamente. Como requisito previo, agregue `pg_cron` al parámetro `shared_preload_libraries` en el grupo de parámetros de la instancia de base de datos.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
A continuación, puede encontrar una explicación paso a paso del ejemplo anterior:
1. Modifique el grupo de parámetros asociado a la instancia de base de datos y agregue `pg_cron` al valor del parámetro `shared_preload_libraries`. Este cambio requiere un reinicio de la instancia de base de datos para que surta efecto. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
1. Ejecute el comando `CREATE EXTENSION pg_cron;` con una cuenta que tenga los permisos `rds_superuser`. Esto habilita la extensión `pg_cron`. Para obtener más información, consulte [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](PostgreSQL_pg_cron.md).
1. Ejecute el comando `UPDATE partman.part_config` para ajustar la configuración de `pg_partman` para la tabla `data_mart.events`.
1. Ejecute el comando `SET` . . . para configurar la tabla `data_mart.events`, con estas cláusulas:
1. `infinite_time_partitions = true,` – Configura la tabla para que pueda crear automáticamente nuevas particiones sin ningún límite.
1. `retention = '3 months',` – Configura la tabla para que tenga una retención máxima de tres meses.
1. `retention_keep_table=true `– Configura la tabla para que cuando venza el periodo de retención, la tabla no se elimine automáticamente. En su lugar, las particiones que son anteriores al periodo de retención solo se separan de la tabla principal.
1. Ejecute el comando `SELECT cron.schedule` . . . para hacer una llamada a la función `pg_cron`. Esta llamada define la frecuencia con la que el programador ejecuta el procedimiento de mantenimiento de `pg_partman`, `partman.run_maintenance_proc`. Para este ejemplo, el procedimiento se ejecuta cada hora.
Para obtener una descripción completa de la función `run_maintenance_proc`, consulte [Funciones de mantenimiento](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions) en la documentación de `pg_partman`.
# Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL
Puede utilizar la extensión `pg_cron` de PostgreSQL para programar comandos de mantenimiento dentro de una base de datos de PostgreSQL. Para obtener más información sobre la extensión, consulte [¿Qué es pg\$1cron?](https://github.com/citusdata/pg_cron) en la documentación de pg\$1cron.
La extensión `pg_cron` es compatible con las versiones 12.6 y posteriores del motor de Aurora PostgreSQL.
Para obtener más información acerca del uso de `pg_cron`, consulte [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL para sus bases de datos de RDS para PostgreSQL o las bases de datos de Aurora PostgreSQL-Compatible Edition](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/)
**nota**
La versión de la extensión de `pg_cron` se muestra como una versión de dos dígitos, por ejemplo, 1.6, en la vista pg\$1available\$1extensions. Si bien es posible que vea versiones de tres dígitos, por ejemplo, 1.6.4 o 1.6.5, en algunos contextos, debe especificar la versión de dos dígitos al realizar una actualización de extensión.
**Topics**
+ [Configuración de la extensión pg\$1cron](#PostgreSQL_pg_cron.enable)
+ [Concesión de permisos para usuarios de base de datos para usar pg\$1cron](#PostgreSQL_pg_cron.permissions)
+ [Programación de trabajos pg\$1cron](#PostgreSQL_pg_cron.examples)
+ [Referencia para la extensión pg\$1cron](#PostgreSQL_pg_cron.reference)
## Configuración de la extensión pg\$1cron
Habilite la extensión de `pg_cron` de la siguiente manera:
1. Modifique el grupo de parámetros personalizado asociado a la instancia de base de datos de PostgreSQL agregando `pg_cron` al valor del parámetro `shared_preload_libraries`.
Reinicie la instancia de base de datos de PostgreSQL para que se apliquen los cambios en el grupo de parámetros. Para obtener más información acerca de cómo trabajar con grupos de parámetros, consulte [Parámetros de Amazon Aurora PostgreSQL.](AuroraPostgreSQL.Reference.ParameterGroups.md).
1. Una vez reiniciada la instancia de base de datos de PostgreSQL, ejecute el siguiente comando con una cuenta que tenga permisos `rds_superuser`. Por ejemplo, si utilizó la configuración predeterminada al crear el clúster de bases de datos de Aurora PostgreSQL, conéctese como usuario `postgres` y cree la extensión.
```
CREATE EXTENSION pg_cron;
```
El programador `pg_cron` se establece en la base de datos de PostgreSQL predeterminada que se denomina `postgres`. Los objetos `pg_cron` se crean en esta base de datos `postgres` y todas las acciones de programación se ejecutan en esta base de datos.
1. Puede utilizar la configuración predeterminada o programar trabajos que ejecutar en otras bases de datos en la instancia de base de datos de PostgreSQL. Para programar trabajos de otras bases de datos en la instancia de base de datos de PostgreSQL, consulte el ejemplo en [Programación de un trabajo cron para una base de datos que no sea la predeterminada](#PostgreSQL_pg_cron.otherDB).
## Concesión de permisos para usuarios de base de datos para usar pg\$1cron
La instalación de la extensión `pg_cron` requiere privilegios de `rds_superuser`. Sin embargo, los permisos para usar `pg_cron` se pueden conceder (los concede un miembro del grupo/rol `rds_superuser`) a otros usuarios de la base de datos para que puedan programar sus propios trabajos. Es recomendable que conceda permisos al esquema `cron` solo según sea necesario si mejora las operaciones en su entorno de producción.
Para conceder permiso a un usuario de base de datos en el esquema `cron`, ejecute el siguiente comando:
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
Esto da permiso *db-user* para acceder al esquema de `cron` para programar trabajos cron para los objetos a los que tienen permiso de acceso. Si el usuario de la base de datos no tiene permisos, se produce un error en el trabajo tras publicar el mensaje de error en el `postgresql.log`, como se muestra a continuación:
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
En otras palabras, asegúrese de que los usuarios de bases de datos a los que se les conceden permisos en el esquema de `cron` también tengan permisos sobre los objetos (tablas, esquemas, etc.) que tienen pensado programar.
Los detalles del trabajo cron y su éxito o fracaso también se capturan en la tabla `cron.job_run_details`. Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables).
## Programación de trabajos pg\$1cron
En las secciones que siguen se muestra cómo programar varias tareas de administración con trabajos `pg_cron`.
**nota**
Al crear trabajos `pg_cron`, compruebe que el valor `max_worker_processes` sea mayor que el número de `cron.max_running_jobs`. Se producirá un error en el trabajo `pg_cron` si se queda sin procesos de trabajo en segundo plano. El número predeterminado de trabajos `pg_cron` es `5`. Para obtener más información, consulte [Parámetros para administrar la extensión pg\$1cron](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [Limpieza de tablas](#PostgreSQL_pg_cron.vacuum)
+ [Depuración de la tabla del historial pg\$1cron](#PostgreSQL_pg_cron.job_run_details)
+ [Registrar errores únicamente en el archivo postgresql.log](#PostgreSQL_pg_cron.log_run)
+ [Programación de un trabajo cron para una base de datos que no sea la predeterminada](#PostgreSQL_pg_cron.otherDB)
### Limpieza de tablas
En la mayoría de los casos, autovacuum maneja el mantenimiento de limpieza. Sin embargo, se recomienda programar una limpieza de una tabla específica en el momento que lo desee.
A continuación, se muestra un ejemplo del uso de la función `cron.schedule` para configurar un trabajo para usar `VACUUM FREEZE` en una tabla específica todos los días a las 22:00 (GMT).
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
Una vez ejecutado el ejemplo anterior, puede comprobar del siguiente modo el historial de la `cron.job_run_details` tabla.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
A continuación, se presenta una consulta de la tabla `cron.job_run_details` para ver los trabajos fallidos.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables).
### Depuración de la tabla del historial pg\$1cron
La tabla `cron.job_run_details` contiene un historial de los trabajos cron que con el tiempo pueden volverse muy grandes. Se recomienda programar un trabajo que depure esta tabla. Por ejemplo, mantener entradas de una semana podría ser suficiente para solucionar problemas.
En el siguiente ejemplo se utiliza la función [cron.schedule](#PostgreSQL_pg_cron.schedule) para programar un trabajo que se ejecuta todos los días a la medianoche para depurar la tabla `cron.job_run_details`. El trabajo mantiene solo los últimos siete días. Utilice su cuenta de `rds_superuser` para programar el trabajo de la siguiente manera:
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables).
### Registrar errores únicamente en el archivo postgresql.log
Para evitar escribir en la tabla `cron.job_run_details`, modifique el grupo de parámetros asociado a la instancia de base de datos de PostgreSQL y establezca el parámetro `cron.log_run` en Off (Desactivado). La extensión `pg_cron` ya no escribe en la tabla y captura errores solo en el archivo `postgresql.log`. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
Utilice el siguiente comando para comprobar el valor del parámetro `cron.log_run`.
```
postgres=> SHOW cron.log_run;
```
Para obtener más información, consulte [Parámetros para administrar la extensión pg\$1cron](#PostgreSQL_pg_cron.parameters).
### Programación de un trabajo cron para una base de datos que no sea la predeterminada
Todos los metadatos de `pg_cron` se mantienen en la base de datos predeterminada de PostgreSQL que se denomina `postgres`. Dado que los trabajadores en segundo plano se utilizan para ejecutar los trabajos cron de mantenimiento, puede programar un trabajo en cualquiera de sus bases de datos dentro de la instancia de base de datos de PostgreSQL:
**nota**
Solo los usuarios con el rol `rds_superuser` o los privilegios `rds_superuser` pueden mostrar todos los trabajos cron en la base de datos. Los demás usuarios solo pueden ver sus propios trabajos en la tabla `cron.job`.
1. En la base de datos cron, programe el trabajo como lo hace normalmente mediante el uso de [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. Como usuario con el rol `rds_superuser`, actualice la columna de base de datos para el trabajo que acaba de crear a fin de que se ejecute en otra base de datos dentro de la instancia de base de datos de PostgreSQL.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Verifique consultando la tabla `cron.job`.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**nota**
En algunas situaciones, puede agregar un trabajo cron que desea ejecutar en otra base de datos. En tales casos, el trabajo podría intentar ejecutarse en la base de datos predeterminada (`postgres`) antes de actualizar la columna de la base de datos correcta. Si el nombre de usuario tiene permisos, el trabajo se ejecuta correctamente en la base de datos predeterminada.
## Referencia para la extensión pg\$1cron
Con la extensión `pg_cron`, puede utilizar los siguientes parámetros, funciones y tablas. Para obtener más información, consulte [¿Qué es pg\$1cron? ](https://github.com/citusdata/pg_cron) en la documentación de pg\$1cron.
**Topics**
+ [Parámetros para administrar la extensión pg\$1cron](#PostgreSQL_pg_cron.parameters)
+ [Referencia de función: cron.schedule](#PostgreSQL_pg_cron.schedule)
+ [Referencia de función: cron.unschedule](#PostgreSQL_pg_cron.unschedule)
+ [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables)
### Parámetros para administrar la extensión pg\$1cron
A continuación, aparece la lista de parámetros para controlar el comportamiento de la extensión `pg_cron`.
| Parámetro | Descripción |
| --- | --- |
| cron.database\$1name | La base de datos en la que se conservan los metadatos de `pg_cron`. |
| cron.host | El nombre de host que se va a conectar a PostgreSQL. No se puede modificar este valor. |
| cron.log\$1run | Registre todos los trabajos que se ejecutan en la tabla `job_run_details`. Los valores son `on` o `off`. Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Registre todas las instrucciones cron antes de ejecutarlas. Los valores son `on` o `off`. |
| cron.max\$1running\$1jobs | La cantidad máxima de trabajos que se pueden ejecutar simultáneamente. |
| cron.use\$1background\$1workers | Utilice procesos de trabajo secundarios en lugar de sesiones de cliente. No se puede modificar este valor. |
Utilice el siguiente comando SQL para mostrar estos parámetros y sus valores:
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Referencia de función: cron.schedule
Esta función programa un trabajo cron. El trabajo se programa inicialmente en la base de datos predeterminada `postgres`. La función devuelve un valor `bigint` que representa el identificador del trabajo. Para programar trabajos para que se ejecuten en otras bases de datos dentro de la instancia de base de datos de PostgreSQL, consulte el ejemplo en [Programación de un trabajo cron para una base de datos que no sea la predeterminada](#PostgreSQL_pg_cron.otherDB).
La función presenta dos formatos de sintaxis.
**Sintaxis**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Parámetros**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_pg_cron.html)
**Ejemplos**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Referencia de función: cron.unschedule
Esta función elimina un trabajo cron. Puede especificar `job_name` o `job_id`. Una política se asegura de que usted es el propietario para quitar la programación del trabajo. La función devuelve un valor booleano que indica éxito o error.
La función tiene los siguientes formatos de sintaxis.
**Sintaxis**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Parámetros**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_pg_cron.html)
**Ejemplos**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tablas para programar trabajos y capturar estado
Las siguientes tablas se crean y utilizan para programar los trabajos cron y registrar la forma en la que se completaron.
| Tabla | Descripción |
| --- | --- |
| cron.job | Contiene los metadatos de cada trabajo programado. La mayoría de las interacciones con esta tabla se deben hacer mediante el uso de las funciones `cron.schedule` y `cron.unschedule`. No recomendamos conceder privilegios de actualización o inserción directamente a esta tabla. Al hacerlo, el usuario podría actualizar la columna `username` para que se ejecute como `rds-superuser`. |
| cron.job\$1run\$1details | Contiene información histórica sobre ejecuciones de trabajos programados anteriores. Esto resulta útil para investigar el estado, los mensajes devueltos y la hora de inicio y finalización de la ejecución del trabajo. Para evitar que esta tabla crezca indefinidamente, púrguela regularmente. Para ver un ejemplo, consulte [Depuración de la tabla del historial pg\$1cron](#PostgreSQL_pg_cron.job_run_details). |
# Uso de pgAudit para registrar la actividad de la base de datos
Las instituciones financieras, las agencias gubernamentales y muchas industrias necesitan mantener *registros de auditoría* para cumplir con los requisitos reglamentarios. Al utilizar la extensión de auditoría de PostgreSQL (PGAudit) con su Clúster de base de datos de Aurora PostgreSQL, puede capturar los registros detallados que suelen necesitar los auditores o para cumplir con los requisitos reglamentarios. Por ejemplo, puede configurar la extensión pgAudit para realizar un seguimiento de los cambios realizados en bases de datos y tablas específicas, para registrar el usuario que realizó el cambio y muchos otros detalles.
La extensión pgAudit se basa en la funcionalidad de la infraestructura de registro nativa de PostgreSQL ampliando los mensajes de registro con más detalle. En otras palabras, utiliza el mismo método para ver el registro de auditoría que para ver cualquier mensaje de registro. Para obtener más información sobre los registros de PostgreSQL, consulte [Archivos de registro de base de datos de Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.md).
La extensión PGAudit elimina los datos confidenciales, como las contraseñas de texto no cifrado, de los registros. Si su clúster de base de datos de Aurora PostgreSQL está configurado para registrar las instrucciones del lenguaje de manipulación de datos (DML) tal como se detalla en [Activación de registro de consultas para su clúster de base de datos de Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md), puede evitar el problema de la contraseña de texto sin cifrar mediante la extensión de auditoría de PostgreSQL.
Puede configurar la auditoría en las instancias de la base de datos con un alto grado de especificidad. Puede auditar todas las bases de datos y todos los usuarios. O bien, puede optar por auditar solo determinadas bases de datos, usuarios y otros objetos. También puede excluir explícitamente a determinados usuarios y bases de datos de la auditoría. Para obtener más información, consulte [Exclusión de usuarios o bases de datos del registro de auditoría](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Dada la cantidad de detalles que se pueden capturar, le recomendamos que, si usa pgAudit, controle su consumo de almacenamiento.
La extensión pgAudit es compatible con todas las versiones de Aurora PostgreSQL disponibles. Para obtener una lista de las versiones de pgAudit compatibles con la versión de Aurora PostgreSQL, consulte [Versiones de extensión para Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) en las *Notas de la versión de Aurora PostgreSQL*.
**Topics**
+ [Configuración de la extensión pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [Auditoría de objetos de base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [Exclusión de usuarios o bases de datos del registro de auditoría](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [Referencia para la extensión pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Configuración de la extensión pgAudit
Para configurar la extensión pgAudit en el clúster de base de datos de Aurora PostgreSQL, primero hay que añadir pgAudit a las bibliotecas compartidas en el grupo de parámetros de clústeres de bases de datos personalizados para su clúster de bases de datos de Aurora PostgreSQL. Para obtener información acerca de cómo crear el grupo de parámetros del clúster de base de datos, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). A continuación, instale la extensión pgAudit. Por último, especifique las bases de datos y objetos que desea auditar. Los procedimientos de esta sección le muestran cómo hacerlo. Puede utilizar la Consola de administración de AWS o la AWS CLI.
Debe tener permisos como el rol `rds_superuser` para realizar todas estas tareas.
En los pasos siguientes se supone que el clúster de ase de datos de Aurora PostgreSQL está asociado a un grupo de parámetros de clúster de base de datos.
## Consola
**Para configurar la extensión pgAudit**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija la instancia de escritor del clúster de base de datos de Aurora PostgreSQL .
1. Abra la pestaña **Configuration** (Configuración) para su instancia de escritor del clúster de base de datos de Aurora PostgreSQL. Entre los detalles de la instancia, busque el enlace del **grupo de parámetros**.
1. Elija el enlace para abrir los parámetros personalizados asociados al clúster de base de datos de Aurora PostgreSQL.
1. En el campo de búsqueda **Parametes** (Parámetros), escriba `shared_pre` para buscar el parámetro `shared_preload_libraries`.
1. Seleccione **Edit parameters** (Editar parámetros) para acceder a los valores de las propiedades.
1. Añada `pgaudit` a la lista en el campo **Values** (Valores). Utilice una coma para separar los elementos de la lista de valores.
![\[Imagen del parámetro shared_preload_libaries con pgAudit añadido.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Reinicie la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL para que surta efecto el cambio en el parámetro `shared_preload_libraries`.
1. Cuando la instancia esté disponible, compruebe que pgAudit se haya inicializado. Use `psql` para conectarse a la instancia de escritor de su clúster de bases de datos Aurora PostgreSQL, y, a continuación, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. Con pgAudit inicializado, ahora puede crear la extensión. Debe crear la extensión después de inicializar la biblioteca, ya que la extensión `pgaudit` instala activadores de eventos para auditar las sentencias del lenguaje de definición de datos (DDL).
```
CREATE EXTENSION pgaudit;
```
1. Cierre la sesión de `psql`.
```
labdb=> \q
```
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Busque el parámetro `pgaudit.log` en la lista y configúrelo con el valor adecuado para su caso de uso. Por ejemplo, al establecer el parámetro `pgaudit.log` en `write` como se muestra en la siguiente imagen, se capturan las inserciones, las actualizaciones, las eliminaciones y algunos otros tipos de cambios en el registro.
![\[Imagen del parámetro pgaudit.log con la configuración.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/rpg_set_pgaudit-log-level.png)
También puede elegir uno de los siguientes valores para el parámetro `pgaudit.log`.
+ none: es el valor predeterminado. No se registran cambios en la base de datos.
+ all: registra todo (read, write, function, role, ddl, misc).
+ ddl: registra todas las instrucciones del lenguaje de definición de datos (DDL) que no están incluidas en la clase `ROLE`.
+ function: registra llamadas a funciones y bloques `DO`.
+ misc: registra comandos variados como, por ejemplo, `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` y `SET`.
+ read: registra `SELECT` y `COPY` cuando el origen es una relación (como una tabla) o una consulta.
+ role: registra instrucciones relacionadas con roles y privilegios, como `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` y `DROP ROLE`.
+ write: registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` y `COPY` cuando el destino es una relación (tabla).
1. Elija **Guardar cambios**.
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Elija su instancia de escritor de clúster de base de datos de Aurora PostgreSQL desde la lista de bases de datos.
## AWS CLI
**Para configurar pgAudit**
Para configurar pgAudit mediante AWS CLI, llame a la operación [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar los parámetros del registro de auditoría de su grupo de parámetros personalizado, como se muestra en el siguiente procedimiento.
1. Utilice el siguiente comando AWS CLI para añadir `pgaudit` al parámetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando AWS CLI para reiniciar la instancia de escritor de la instancia de base de datos de Aurora PostgreSQL para que se inicialice la biblioteca pgaudit.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, puede verificar si `pgaudit` se ha inicializado. Use `psql` para conectarse a la instancia de escritor de su clúster de bases de datos Aurora PostgreSQL, y, a continuación, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
Con pgAudit inicializado, ahora puede crear la extensión.
```
CREATE EXTENSION pgaudit;
```
1. Cierre la sesión de `psql` para poder utilizar AWS CLI.
```
labdb=> \q
```
1. Utilice el siguiente comando AWS CLI para especificar las clases de instrucciones que desea registrar con el registro de auditoría de sesión. El ejemplo establece el parámetro `pgaudit.log` en`write`, que captura las inserciones, las actualizaciones y las eliminaciones del registro.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
También puede elegir uno de los siguientes valores para el parámetro `pgaudit.log`.
+ none: es el valor predeterminado. No se registran cambios en la base de datos.
+ all: registra todo (read, write, function, role, ddl, misc).
+ ddl: registra todas las instrucciones del lenguaje de definición de datos (DDL) que no están incluidas en la clase `ROLE`.
+ function: registra llamadas a funciones y bloques `DO`.
+ misc: registra comandos variados como, por ejemplo, `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` y `SET`.
+ read: registra `SELECT` y `COPY` cuando el origen es una relación (como una tabla) o una consulta.
+ role: registra instrucciones relacionadas con roles y privilegios, como `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` y `DROP ROLE`.
+ write: registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` y `COPY` cuando el destino es una relación (tabla).
Reinicie la instancia de escritor de su clúster de bases de datos Aurora PostgreSQL mediante el siguiente comando AWS CLI.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
# Auditoría de objetos de base de datos
Con PGAudit configurado en su clúster de base de datos de Aurora PostgreSQL y configurado según sus requisitos, se captura información más detallada en el registro de PostgreSQL. Por ejemplo, si bien la configuración de registro predeterminada de PostgreSQL identifica la fecha y la hora en que se realizó un cambio en una tabla de base de datos, con la extensión pgAudit la entrada de registro puede incluir el esquema, el usuario que realizó el cambio y otros detalles, según cómo estén configurados los parámetros de la extensión. Puede configurar la auditoría para realizar un seguimiento de los cambios de las siguientes maneras.
+ Para cada sesión, por usuario. Para el nivel de sesión, puede capturar el texto completo del comando.
+ Para cada objeto, por usuario y por base de datos.
La capacidad de auditoría de objetos se activa cuando se crea el rol `rds_pgaudit` en el sistema y, a continuación, se agrega este rol al parámetro `pgaudit.role` del grupo de parámetros personalizados. De forma predeterminada, el parámetro `pgaudit.role` no está configurado y el único valor permitido es `rds_pgaudit`. En los siguientes pasos se asume que `pgaudit` se ha inicializado y que ha se ha creado la extensión `pgaudit` siguiendo el procedimiento descrito en [Configuración de la extensión pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
![\[Imagen del archivo de registro de PostgreSQL después de configurar pgAudit.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/pgaudit-log-example.png)
Como se muestra en este ejemplo, la línea «LOG: AUDIT: SESSION» proporciona información sobre la tabla y su esquema, entre otros detalles.
**Para configurar la auditoría de objetos**
1. Use `psql` para conectarse a la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL.
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Cree un rol de base de datos llamado `rds_pgaudit` mediante el siguiente comando.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Cierre la sesión de `psql`.
```
labdb=> \q
```
En los siguientes pasos, use elAWS CLI para modificar los parámetros del registro de auditoría en el grupo de parámetros personalizado.
1. Utilice el siguiente comando AWS CLI para establecer el parámetro `pgaudit.role` en `rds_pgaudit`. De forma predeterminada, este parámetro está vacío y `rds_pgaudit` es el único valor permitido.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Reinicie AWS CLIla instancia de escritor de su clúster de base de datos de Aurora PostgreSQL para que sus cambios en los parámetros surtan efecto.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. Ejecute el siguiente comando para confirmar que `pgaudit.role` se establece en `rds_pgaudit`.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
Para probar el registro de pgAudit, puede ejecutar varios comandos de ejemplo que desee auditar. Por ejemplo, podría ejecutar los siguientes comandos.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
Los registros de base de datos contendrán una entrada similar a la siguiente.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
Para obtener información acerca de la visualización de los registros, consulte [Supervisión de archivos de registro de Amazon Aurora](USER_LogAccess.md).
Para obtener más información sobre la extensión pgAudit, consulte [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md) en GitHub.
# Exclusión de usuarios o bases de datos del registro de auditoría
Como se explica en [Archivos de registro de base de datos de Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.md), los registros de PostgreSQL consumen espacio de almacenamiento. El uso de la extensión pgAudit aumenta el volumen de datos recopilados en los registros en diversos grados, según los cambios de los que realice un seguimiento. Es posible que no necesite auditar todos los usuarios o bases de datos de su clúster de base de datos de Aurora PostgreSQL.
Para minimizar los impactos en el almacenamiento y evitar la captura innecesaria de registros de auditoría, puede excluir a los usuarios y las bases de datos de la auditoría. También puede cambiar el registro dentro de una sesión determinada. Los siguientes ejemplos muestran cola forma de hacerlo.
**nota**
La configuración de los parámetros a nivel de sesión tiene prioridad sobre la configuración del grupo de parámetros del grupo de parámetros del clúster DB personalizado para la instancia de escritor del clúster DB de Aurora PostgreSQL. Si no desea que los usuarios de la base de datos omitan los ajustes de configuración del registro de auditoría, asegúrese de cambiar sus permisos.
Supongamos que su clúster de base de datos de Aurora PostgreSQL está configurado para auditar el mismo nivel de actividad para todos los usuarios y bases de datos. A continuación, decide que no desea auditar al usuario `myuser`. Puede desactivar la auditoría de `myuser` con el siguiente comando de SQL.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
A continuación, puede utilizar la siguiente consulta para comprobar la columna `user_specific_settings` de `pgaudit.log` para confirmar que el parámetro está establecido en `NONE`.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
Debería ver una salida como la siguiente.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
Puede desactivar el registro de un usuario determinado en medio de su sesión con la base de datos con el siguiente comando.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Utilice la siguiente consulta para comprobar la columna de configuración de pgaudit.log para una combinación específica de usuario y base de datos.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
Se muestra una salida similar a la siguiente.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
Tras desactivar la auditoría de `myuser`, decide que no desea realizar un seguimiento de los cambios en `mydatabase`. Puede desactivar la auditoría de esa base de datos específica mediante el siguiente comando.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
A continuación, utilice la siguiente consulta para comprobar la columna database\$1specific\$1settings y confirmar que pgaudit.log tiene el valor NONE.
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
Debería ver una salida como la siguiente.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
Para restablecer la configuración predeterminada de myuser, use el siguiente comando:
```
ALTER USER myuser RESET pgaudit.log;
```
Para restablecer la configuración predeterminada de una base de datos, use el siguiente comando:
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
Para restablecer el usuario y la base de datos a la configuración por defecto, utilice el siguiente comando.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
También puede capturar eventos específicos en el registro configurando `pgaudit.log` en uno de los otros valores permitidos para el parámetro `pgaudit.log`. Para obtener más información, consulte [Lista de ajustes permitidos para el parámetro `pgaudit.log`](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Referencia para la extensión pgAudit
Puede especificar el nivel de detalle que desea para el registro de auditoría cambiando uno o más de los parámetros que se enumeran en esta sección.
## Control del comportamiento de pgAudit
Puede controlar el registro de auditoría cambiando uno o más de los parámetros que aparecen en la tabla siguiente.
| Parámetro | Descripción |
| --- | --- |
| `pgaudit.log` | Especifica las clases de instrucciones que se registrarán mediante el registro de auditoría de sesión. Los valores permitidos incluyen ddl, function, misc, read, role, write, none, all. Para obtener más información, consulte [Lista de ajustes permitidos para el parámetro `pgaudit.log`](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | Cuando se activa (se establece en 1), agrega instrucciones al registro de auditoría si todas las relaciones de una instrucción se encuentran en pg\$1catalog. |
| `pgaudit.log_level` | Especifica el nivel de registro que se usará para las entradas de registro. Valores permitidos, debug5, debug4, debug3, debug2, debug1, info, notice, warning, log. |
| `pgaudit.log_parameter` | Cuando se activa (se establece en 1), los parámetros transmitidos con la instrucción se capturan en el registro de auditoría. |
| `pgaudit.log_relation` | Cuando se activa (se establece en 1), el registro de auditoría de la sesión crea una entrada de registro separada para cada relación (TABLE, VIEW, etc.) referenciada en una instrucción SELECT o DML. |
| `pgaudit.log_statement_once` | Especifica si el registro incluirá el texto de la instrucción y los parámetros con la primera entrada de registro para una combinación de instrucción o subinstrucción o con cada entrada. |
| `pgaudit.role` | Especifica el rol maestro que se usará para el registro de auditoría de objetos. La única entrada permitida es `rds_pgaudit`. |
## Lista de ajustes permitidos para el parámetro `pgaudit.log`
| Valor | Descripción |
| --- | --- |
| none | Esta es la opción predeterminada. No se registran cambios en la base de datos. |
| all | Registra todo (read, write, function, role, ddl, misc). |
| ddl | Registra todas las instrucciones del lenguaje de definición de datos (DDL) que no están incluidas en la clase `ROLE`. |
| función | Registra llamadas a funciones y bloques `DO`. |
| misc | Registra comandos variados como, por ejemplo, `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` y `SET`. |
| lectura | Registra `SELECT` y `COPY` cuando el origen es una relación (como una tabla) o una consulta. |
| rol | Registra instrucciones relacionadas con roles y privilegios, como, por ejemplo, `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` y `DROP ROLE`. |
| escritura | Registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` y `COPY` cuando el destino es una relación (tabla). |
Para registrar varios tipos de eventos con auditorías de sesiones, utilice una lista separada por comas. Para registrar todos los tipos de eventos, establezca `pgaudit.log` en `ALL`. Reinicie la instancia de base de datos para aplicar los cambios.
Con la auditoría de objetos, puede mejorar los registros de auditoría para que funcionen con algunas relaciones específicas. Por ejemplo, puede especificar que desea crear registros de auditoría para las operaciones `READ` en una o más tablas.
# Uso de pglogical para sincronizar datos entre instancias
Todas las versiones de Aurora PostgreSQL disponibles actualmente admiten la extensión `pglogical`. La extensión pglogical es anterior a la función de replicación lógica funcionalmente similar que se introdujo en la versión 10 de PostgreSQL. Para obtener más información, consulte [Información general sobre la replicación lógica de PostgreSQL con Aurora](AuroraPostgreSQL.Replication.Logical.md).
La extensión `pglogical` admite la replicación lógica entre dos o más clústeres de base de datos de Aurora PostgreSQL. También admite la replicación entre diferentes versiones de PostgreSQL y entre bases de datos que se ejecutan en instancias de base de datos de RDS para PostgreSQL y clústeres de bases de datos de Aurora PostgreSQL. La extensión `pglogical` utiliza un modelo de publicación y suscripción para replicar los cambios en las tablas y otros objetos, como secuencias, de un publicador a un suscriptor. Se basa en una ranura de replicación para garantizar que los cambios se sincronicen de un nodo publicador a un nodo suscriptor, que se define de la siguiente manera.
+ El *nodo publicador* es el clúster de base de datos de Aurora PostgreSQL, que es la fuente de datos que se van a replicar en otros nodos. El nodo publicador define las tablas que se van a replicar en un conjunto de publicaciones.
+ El *nodo suscriptor* es el clúster de base de datos de Aurora PostgreSQL que recibe las actualizaciones WAL del publicador. El suscriptor crea una suscripción para conectarse al publicador y obtener los datos WAL decodificados. Cuando el suscriptor crea la suscripción, se crea la ranura de replicación en el nodo del publicador.
A continuación, encontrará información sobre cómo configurar la extensión `pglogical`.
**Topics**
+ [Requisitos y limitaciones de la extensión pglogical](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [Configuración de la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [Restablecimiento de la replicación lógica después de una actualización principal](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [Administración de ranuras de replicación lógica para Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [Referencia de parámetros para la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Requisitos y limitaciones de la extensión pglogical
Todas las versiones disponibles actualmente de Aurora PostgreSQL admiten la extensión `pglogical`.
Tanto el nodo publicador como el nodo suscriptor deben estar configurados para la replicación lógica.
Las tablas que desee replicar desde un publicador a un suscriptor deben tener los mismos nombres y el mismo esquema. Estas tablas también deben contener las mismas columnas y las columnas deben utilizar los mismos tipos de datos. Tanto las tablas de los publicadores como las de suscriptores deben tener las mismas claves principales. Se recomienda utilizar únicamente la PRIMARY KEY como restricción única.
Las tablas del nodo suscriptor pueden tener restricciones más permisivas que las del nodo publicador para las restricciones CHECK y NOT NULL.
La extensión `pglogical` proporciona funciones como la replicación bidireccional que no son compatibles con la función de replicación lógica integrada en PostgreSQL (versión 10 y posteriores). Para obtener más información, consulte [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Replicación bidireccional de PostgreSQL mediante pglogical).
# Configuración de la extensión pglogical
Para configurar la extensión `pglogical` en el clúster de base de datos de Aurora PostgreSQL, añada `pglogical` a las bibliotecas compartidas en el grupo de parámetros de clúster de bases de datos personalizado para su clúster de bases de datos de Aurora PostgreSQL. También debe establecer el valor del parámetro `rds.logical_replication` en `1` para activar la descodificación lógica. Por último, cree la extensión en la base de datos. Puede utilizar la Consola de administración de AWS o la AWS CLI para estas tareas.
Debe tener permisos como el rol `rds_superuser` para realizar estas tareas.
En los pasos siguientes se supone que su clúster de base de datos de Aurora PostgreSQL está asociado a un grupo de parámetros de clúster de base de datos personalizado. Para obtener información acerca de cómo crear el grupo de parámetros del clúster de base de datos, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md).
## Consola
**Para configurar la extensión pglogical**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija la instancia de escritor del clúster de base de datos de Aurora PostgreSQL .
1. Abra la pestaña **Configuration** (Configuración) para su instancia de escritor del clúster de base de datos de Aurora PostgreSQL. Entre los detalles de la instancia, busque el enlace del **grupo de parámetros**.
1. Elija el enlace para abrir los parámetros personalizados asociados al clúster de base de datos de Aurora PostgreSQL.
1. En el campo de búsqueda **Parametes** (Parámetros), escriba `shared_pre` para buscar el parámetro `shared_preload_libraries`.
1. Seleccione **Edit parameters** (Editar parámetros) para acceder a los valores de las propiedades.
1. Añada `pglogical` a la lista en el campo **Values** (Valores). Utilice una coma para separar los elementos de la lista de valores.
![\[Imagen del parámetro shared_preload_libraries con pglogical añadido.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Busque el parámetro `rds.logical_replication` y configúrelo en `1` para activar la replicación lógica.
1. Reinicie la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL para que surtan efecto los cambios.
1. Cuando la instancia esté disponible, puede usar `psql` (o pgAdmin) para conectarse a la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Para comprobar que pglogical esté inicializado, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Compruebe la configuración que permite la descodificación lógica, de la siguiente manera.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Cree la extensión de la siguiente manera.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Seleccione **Save changes (Guardar cambios)**.
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Elija la instancia de escritura del clúster de RDS for PostgreSQL en la lista de bases de datos para seleccionarla y, a continuación, elija **Reboot** (Reiniciar) en el menú Actions (Acciones).
## AWS CLI
**Para configurar la extensión pglogical**
Para configurar pglogical mediante la AWS CLI, llame a la operación [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar determinados parámetros de su grupo de parámetros personalizado, tal como se muestra en el siguiente procedimiento.
1. Utilice el siguiente comando AWS CLI para añadir `pglogical` al parámetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando AWS CLI para configurar `rds.logical_replication` en `1` y activar la función de descodificación lógica para la instancia de escritor del clúster de base de datos de Aurora PostgreSQL.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando AWS CLI para reiniciar la instancia de escritor de la instancia de base de datos de Aurora PostgreSQL para que se inicialice la biblioteca de pglogical.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, use `psql` para conectarse a la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Cree la extensión de la siguiente manera.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Reinicie la instancia de escritor de su clúster de bases de datos Aurora PostgreSQL mediante el siguiente comando AWS CLI.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
# Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL
En el siguiente procedimiento, se muestra cómo iniciar la replicación lógica entre dos clústeres de base de datos de Aurora PostgreSQL. En los pasos, se asume que tanto el origen (publicador) como el destino (suscriptor) tienen la extensión `pglogical` configurada como se detalla en [Configuración de la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
**nota**
El `node_name` de un nodo de suscriptor no puede empezar por `rds`.
**Para crear el nodo publicador y definir las tablas que se van a replicar**
En estos pasos se asume que el clúster de base de datos de Aurora PostgreSQL tiene una instancia de escritor con una base de datos que tiene una o más tablas que desea replicar en otro nodo. Debe volver a crear la estructura de tablas del publicador en el suscriptor, así que primero debe obtener la estructura de la tabla si es necesario. Para ello, utilice el metacomando de `psql` `\d tablename` y, a continuación, cree la misma tabla en la instancia del suscriptor. El siguiente procedimiento crea una tabla de ejemplo en el publicador (origen) con fines de demostración.
1. Utilice `psql` para conectarse a la instancia que tiene la tabla que desea usar como origen para los suscriptores.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
Si no dispone de una tabla existente que desee replicar, puede crear una tabla de ejemplo de la siguiente manera.
1. Cree una tabla de ejemplo con la siguiente instrucción SQL.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Rellene la tabla con los datos generados mediante la siguiente instrucción SQL.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Compruebe que los datos existen en la tabla mediante la siguiente instrucción SQL.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identifique este clúster de base de datos de Aurora PostgreSQL como nodo publicador de la siguiente manera.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Añada la tabla que desea replicar al conjunto de replicación predeterminado. Para obtener más información sobre los conjuntos de replicación, consulte [Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) (Conjuntos de replicación) en la documentación de pglogical.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
Se ha completado la configuración del nodo publicador. Ahora puede configurar el nodo suscriptor para recibir las actualizaciones del publicador.
**Para configurar el nodo suscriptor y crear una suscripción para recibir actualizaciones**
En estos pasos se asume que el clúster de base de datos de Aurora PostgreSQL se ha configurado con la extensión `pglogical`. Para obtener más información, consulte [Configuración de la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Utilice `psql` para conectarse a la instancia en la que desea recibir actualizaciones del publicador.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. En el clúster de base de datos de Aurora PostgreSQL, del suscriptor, cree la misma tabla que existe en el publicador. En este ejemplo, la tabla es `docs_lab_table`. Puede crear la tabla tal y como se indica a continuación.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Compruebe que esta tabla esté vacía.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identifique este clúster de base de datos de Aurora PostgreSQL como nodo suscriptor de la siguiente manera.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Cree la suscripción.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
Al completar este paso, los datos de la tabla del publicador se crean en la tabla del suscriptor. Para comprobar que ha ocurrido esto, utilice la siguiente consulta SQL.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
A partir de este momento, los cambios realizados en la tabla del publicador se replicarán en la tabla del suscriptor.
# Restablecimiento de la replicación lógica después de una actualización principal
Para poder realizar una actualización de una versión principal de un clúster de base de datos de Aurora PostgreSQL que se haya configurado como nodo publicador para la replicación lógica, debe eliminar todas las ranuras de replicación, incluso las que no estén activas. Se recomienda desviar temporalmente las transacciones de la base de datos del nodo publicador, eliminar las ranuras de replicación, actualizar el clúster de base de datos de Aurora PostgreSQL, y, a continuación, restablecer y reiniciar la replicación.
Las ranuras de replicación se alojan únicamente en el nodo publicador. El nodo suscriptor de Aurora PostgreSQL en un escenario de replicación lógica no tiene ranuras que eliminar. El proceso de actualización de la versión principal de Aurora PostgreSQL permite actualizar el suscriptor a una nueva versión principal de PostgreSQL independiente del nodo publicador. Sin embargo, el proceso de actualización interrumpe el proceso de replicación e interfiere con la sincronización de los datos WAL entre el nodo publicador y el nodo suscriptor. Debe restablecer la replicación lógica entre el publicador y el suscriptor después de actualizar el publicador, el suscriptor o ambos. En el procedimiento siguiente se muestra cómo determinar que se ha interrumpido la replicación y cómo resolver el problema.
## Determinación de que la replicación lógica se ha interrumpido
Puede determinar que el proceso de replicación se ha interrumpido consultando el nodo publicador o el nodo suscriptor de la siguiente manera.
**Para comprobar el nodo publicador**
+ Utilice `psql` para conectarse al nodo publicador y, a continuación, consulte la función `pg_replication_slots`. Anote el valor de la columna activa. Normalmente, esto devolverá `t` (true) y mostrará que la replicación está activa. Si la consulta devuelve `f` (false), indica que la replicación en el suscriptor se ha detenido.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**Para comprobar el nodo suscriptor**
En el nodo suscriptor, puede comprobar el estado de la replicación de tres maneras diferentes.
+ Revise los registros de PostgreSQL en el nodo suscriptor para encontrar los mensajes de error. El registro identifica el error con mensajes que incluyen el código de salida 1, como se muestra a continuación.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Consulte la función `pg_replication_origin`. Conéctese a la base de datos en el nodo suscriptor mediante `psql` y consulte la función `pg_replication_origin` de la siguiente manera.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
Un conjunto de resultados vacío significa que la replicación se ha interrumpido. Debería ver una salida como la siguiente.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Consulte la función `pglogical.show_subscription_status` tal y como se muestra en el siguiente ejemplo.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
Este resultado muestra que la replicación se ha interrumpido. Su estado es `down`. Normalmente, la salida muestra el estado como `replicating`.
Si el proceso de replicación lógica se ha interrumpido, puede restablecerla siguiendo estos pasos.
**Para restablecer la replicación lógica entre los nodos publicador y suscriptor**
Para restablecer la replicación, primero debe desconectar el suscriptor del nodo publicador y, a continuación, restablecer la suscripción, tal como se describe en estos pasos.
1. Conéctese al nodo suscriptor con `psql` de la siguiente manera.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Desactive la suscripción mediante la función `pglogical.alter_subscription_disable`.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Obtenga el identificador del nodo publicador consultando el `pg_replication_origin` de la siguiente manera.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Utilice la respuesta del paso anterior con el comando `pg_replication_origin_create` para asignar el identificador que podrá utilizar la suscripción cuando se restablezca.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Para activar la suscripción, introduzca su nombre con un estado de `true`, tal como se muestra en el ejemplo siguiente.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Compruebe el estado del nodo. Su estado debería ser `replicating`, tal y como se muestra en este ejemplo.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Compruebe el estado de la ranura de replicación del suscriptor en el nodo publicador. La columna `active` de la ranura debe devolver `t` (true), lo que indica que se ha restablecido la replicación.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Administración de ranuras de replicación lógica para Aurora PostgreSQL
Para poder realizar una actualización de una versión principal en una instancia de escritor de base de datos de Aurora PostgreSQL que se utilice como nodo publicador en un escenario de replicación lógica, debe eliminar todas las ranuras de replicación de la instancia. El proceso de comprobación previa de la actualización de la versión principal le indica que la actualización no puede continuar hasta que se eliminen las ranuras disponibles.
Para identificar las ranuras de replicación que se crearon con la extensión `pglogical`, inicie sesión en cada base de datos y obtenga el nombre de los nodos. Al consultar el nodo suscriptor, aparecen los nodos publicador y suscriptor en el resultado, tal como se muestra en este ejemplo.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
Puede obtener los detalles de la suscripción con la siguiente consulta.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
Ahora puede eliminar la suscripción de la siguiente manera.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
Después de eliminar la suscripción, puede eliminar el nodo.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
Puede comprobar que el nodo ya no existe de la siguiente manera.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Referencia de parámetros para la extensión pglogical
En la tabla verá los parámetros asociados a la extensión `pglogical`. Parámetros como `pglogical.conflict_log_level` y `pglogical.conflict_resolution` se utilizan para gestionar los conflictos de actualización. Pueden surgir conflictos cuando los cambios se realizan localmente en las mismas tablas que están suscritas a los cambios del publicador. Los conflictos también pueden producirse en varios escenarios, como la replicación bidireccional o cuando varios suscriptores replican desde el mismo publicador. Para obtener más información, consulte [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Replicación bidireccional de PostgreSQL mediante pglogical).
| Parámetro | Descripción |
| --- | --- |
| pglogical.batch\$1inserts | Inserciones por lotes si es posible. No establecido de manera predeterminada. Se cambia a 1 para activarlo y a 0 para desactivarlo. |
| pglogical.conflict\$1log\$1level | Establece el nivel de registro utilizado para registrar los conflictos resueltos. Los valores permitidos son debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal y panic. |
| pglogical.conflict\$1resolution | Establece el método que se utilizará para resolver conflictos si es posible resolverlos. Los valores de cadena admitidos son error, apply\$1remote, keep\$1local, last\$1update\$1wins y first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Opciones de conexión a añadir a todas las conexiones de los nodos pares. |
| pglogical.synchronous\$1commit | valor de confirmación sincrónica específico de pglogical |
| pglogical.use\$1spi | Utilice la SPI (interfaz de programación de servidores) en lugar de la API de nivel inferior para aplicar los cambios. Se establece en 1 para activarlo y en 0 para desactivarlo. Para obtener más información acerca de la SPI, consulte [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) (Interfaz de programación de servidores) en la documentación de PostgreSQL. |
# Uso de los contenedores de datos externos compatibles para Amazon Aurora PostgreSQL
Un FDW es un tipo específico de extensión que proporciona acceso a datos externos. Por ejemplo, la extensión `oracle_fdw` permite a su Instancia de base de datos de Aurora PostgreSQL trabajar con bases de datos Oracle.
A continuación, puede encontrar información sobre varios contenedores de datos externos de PostgreSQL compatibles.
**Topics**
+ [Uso de la extensión log\$1fdw para acceder al registro de base de datos mediante SQL](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [Uso de la extensión postgres\$1fdw para acceder a datos externos](postgresql-commondbatasks-fdw.md)
+ [Uso de bases de datos MySQL con la extensión mysql\$1fdw](postgresql-mysql-fdw.md)
+ [Uso de una base de datos de Oracle con la extensión oracle\$1fdw](postgresql-oracle-fdw.md)
+ [Uso de bases de datos de SQL Server con la extensión mysql\$1fdw](postgresql-tds-fdw.md)
# Uso de la extensión log\$1fdw para acceder al registro de base de datos mediante SQL
El clúster de base de datos de Aurora PostgreSQL admite la extensión `log_fdw`, que se puede utilizar para el acceso al registro del motor de base de datos a través de una interfaz SQL. La extensión `log_fdw` proporciona dos funciones que facilitan la creación de tablas externas para los registros de la base de datos:
+ `list_postgres_log_files`: muestra los archivos del directorio de registro de la base de datos y el tamaño del archivo en bytes.
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)`: crea una tabla externa para el archivo especificado en la base de datos actual.
Todas las funciones creadas por `log_fdw` pertenecen a `rds_superuser`. Los miembros del rol `rds_superuser` pueden conceder acceso a estas funciones a otros usuarios de la base de datos.
De forma predeterminada, Amazon Aurora genera los archivos de registro en formato `stderr` (error estándar), como se especifica en el parámetro `log_destination`. Solo hay dos opciones para este parámetro: `stderr` y `csvlog` (valores separados por comas, CSV). Si se añade la opción `csvlog` al parámetro, Amazon Aurora generará tanto el registro `stderr` como el registro `csvlog`. Esto puede afectar a la capacidad de almacenamiento del clúster de base de datos, por lo que debe tener en cuenta los demás parámetros que afectan a la gestión de jlos registros. Para obtener más información, consulte [Configuración del destino del registro (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format).
Uno de los beneficios de generar registros `csvlog` es que la extensión `log_fdw` permite crear tablas externas con los datos perfectamente divididos en varias columnas. Para ello, la instancia debe asociarse a un grupo de parámetros de base de datos personalizado para que usted pueda cambiar la configuración de `log_destination`. Para obtener información acerca de cómo hacerlo, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md).
En el ejemplo siguiente se presupone que el parámetro `log_destination` incluye `cvslog`.
**Para utilizar la extensión log\$1fdw**
1. Instale la extensión de `log_fdw`.
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. Cree el servidor de registros como contenedor de datos externo.
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. Seleccione todos los elementos de una lista de archivos de registro.
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
A continuación, se muestra una respuesta de ejemplo.
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. Crear una tabla con una sola columna log\$1entry para el archivo seleccionado.
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
La respuesta no proporciona más detalles que el hecho de que la tabla ya existe.
```
-----------------------------------
(1 row)
```
1. Seleccione una muestra del archivo de registro. El siguiente código recupera la hora del registro y la descripción del mensaje de error.
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
A continuación, se muestra una respuesta de ejemplo.
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# Uso de la extensión postgres\$1fdw para acceder a datos externos
Puede acceder a los datos en una tabla en un servidor de base de datos remoto con la extensión [postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html). Si establece una conexión remota desde su instancia de base de datos de PostgreSQL, el acceso también está disponible para su réplica de lectura.
**Para utilizar postgres\$1fdw para acceder a un servidor de base de datos remoto**
1. Instale la extensión postgres\$1fdw.
```
CREATE EXTENSION postgres_fdw;
```
1. Cree el servidor de datos externo utilizando CREATE SERVER.
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. Cree un mapeo de usuario para identificar la función que utilizar en el servidor remoto.
**importante**
Para redactar la contraseña para que no aparezca en los registros, configure `log_statement=none` en el nivel de sesión. Si se establece en el nivel de parámetro, no se redacta la contraseña.
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. Cree una tabla que se mapee a la tabla del servidor remoto.
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# Uso de bases de datos MySQL con la extensión mysql\$1fdw
Para tener acceso desde un clúster de base de datos de Aurora PostgreSQL a una base de datos compatible con MySQL, puede instalar y utilizar la extensión `mysql_fdw`. Este contenedor de datos externo le permite trabajar con RDS for MySQL, Aurora MySQL, MariaDB y otras bases de datos compatibles con MySQL. La conexión desde el clúster de base de datos de Aurora PostgreSQL a la base de datos MySQL se cifra tanto como sea posible, depeniendo de la configuración del cliente y del servidor. No obstante, puede aplicar cifrado si lo desea. Para obtener más información, consulte [Uso de cifrado en tránsito con la extensión](#postgresql-mysql-fdw.encryption-in-transit).
La extensión `mysql_fdw` es complatible con las versiones de Amazon Aurora PostgreSQL 15.4, 14,9, 13.12, 12.16 y posteriores. Es compatible con selecciones, inserciones, actualizaciones y eliminaciones de una base de datos de RDS for PostgreSQL en tablas de una instancia de base de datos compatible con MySQL.
**Topics**
+ [Configuración de una base de datos de Aurora PostgreSQL para utilizar la extensión mysql\$1fdw](#postgresql-mysql-fdw.setting-up)
+ [Ejemplo: Acceso a una base de datos de Aurora MySQL desde Aurora PostgreSQL](#postgresql-mysql-fdw.using-mysql_fdw)
+ [Uso de cifrado en tránsito con la extensión](#postgresql-mysql-fdw.encryption-in-transit)
## Configuración de una base de datos de Aurora PostgreSQL para utilizar la extensión mysql\$1fdw
Para configurar la extensión `mysql_fdw` en el clúster de base de datos de Aurora PostgreSQL es necesario cargar la extensión en el clúster y, a continuación, crear el punto de conexión a la instancia de base de datos de MySQL. Para esa tarea debe disponer de los siguientes detalles sobre la instancia de base de datos MySQL:
+ Nombre de host o del punto de conexión. Con un clúster de base de datos de Aurora MySQL el punto de conexión puede encontrarse a través de la consola. Elija la pestaña Conectividad y seguridad y busque en la sección “Punto de enlace y puerto”.
+ Número de puerto. El número de puerto predeterminado para MySQL es 3306.
+ Nombre de la base de datos. El identificador de la base de datos.
También tiene que proporcionar acceso en el grupo de seguridad o en la lista de control de acceso (ACL) para el puerto MySQL, 3306. Tanto el clúster de base de datos de Aurora PostgreSQL como el de Aurora MySQL necesitan acceso al puerto 3306. Si el acceso no está configurado correctamente, al intentar conectarse a una tabla compatible con MySQL aparecerá un mensaje de error similar al siguiente:
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
En el procedimiento que sigue, usted (como cuenta de `rds_superuser`) crea el servidor externo. A continuación, concede acceso al servidor externo a usuarios específicos. A continuación, estos usuarios crean sus propias asignaciones a las cuentas de usuario de MySQL adecuadas para trabajar con la instancia de base de datos MySQL.
**Para utilizar mysql\$1fdw para acceder a un servidor de base de datos MySQL**
1. Conéctese a la instancia de base de datos PostgreSQL a través de una cuenta que tenga el rol de `rds_superuser`. Si al crear el clúster de base de datos de Aurora PostgreSQL aceptó los valores predeterminados, el nombre de usuario será `postgres` y se podrá conectar mediante la herramienta de línea de comandos `psql` de este modo:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. Instale la extensión `mysql_fdw` de la siguiente manera:
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
Una vez instalada la extensión en el clúster de base de datos de Aurora PostgreSQL, configure el servidor externo que proporciona la conexión a una base de datos MySQL.
**Para crear el servidor externo**
Realice estas tareas en el clúster de bases de datos de Aurora PostgreSQL. Para seguir estos pasos se entiende que está conectado como usuario con privilegios `rds_superuser`, como `postgres`.
1. Cree un servidor externo en el clúster de bases de datos Aurora PostgreSQL:
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Conceda a los usuarios que corresponsa acceso al servidor externo. Deben ser usuarios que no sean administradores, es decir, usuarios que no tengan el rol `rds_superuser`.
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
Los usuarios de PostgreSQL crean y administran sus propias conexiones a la base de datos MySQL a través del servidor externo.
## Ejemplo: Acceso a una base de datos de Aurora MySQL desde Aurora PostgreSQL
Supongamos que tiene una tabla simple en una instancia de base de datos de Aurora PostgreSQL. Sus usuarios de Aurora PostgreSQL quieren consultar los elementos `SELECT`, `INSERT`, `UPDATE` y `DELETE` en esa tabla. Supongamos que la exstensión `mysql_fdw` se creó en la instancia de base de datos de RDS for PostgreSQL, como se detalla en el procedimiento anterior. Después de conectarse a la instancia de base de datos de RDS for PostgreSQL como usuario con privilegios `rds_superuser`, podrá continuar con los pasos que se describen a continuación.
1. Cree un servidor externo en la instancia de base de datos de Aurora PostgreSQL:
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Conceda permiso de uso a un usuario que no tiene permisos `rds_superuser`, por ejemplo `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. Conéctese como*user1* y, a continuación, cree una asignación para el usuario de MySQL:
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. Cree una tabla externa vinculada a la tabla MySQL:
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. Ejecute una consulta simple en la tabla externa:
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. Puede añadir, modificar y quitar datos de la tabla MySQL. Por ejemplo:
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
Ejecute la consulta `SELECT` de nuevo para ver los resultados:
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## Uso de cifrado en tránsito con la extensión
De forma predeterminada, la conexión a MySQL desde Aurora PostgreSQL utiliza cifrado en tránsito (TLS/SSL). No obstante, la conexión vuelve a ser no cifrada cuando la configuración del cliente y del servidor difieren. Puede aplicar el cifrado para todas las conexiones salientes especificando la opción `REQUIRE SSL` en las cuentas de usuario de RDS for MySQL. Este mismo método también funciona para las cuentas de usuario de MariaDB y Aurora MySQL.
Para cuentas de usuario MySQL configuradas en `REQUIRE SSL`, el intento de conexión falla si no se puede establecer una conexión segura.
Para aplicar el cifrado de cuentas de usuario de bases de datos MySQL existentes, puede utilizar el comando `ALTER USER`. La sintaxis varía en función de la versión de MySQL, como se muestra en la siguiente tabla. Para obtener más información, consulte [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) en el *manual de referencia de MySQL*.
| MySQL 5.7, MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
Para obtener más información acerca de la extensión `mysql_fdw`, consulte la documentación sobre [mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw).
# Uso de una base de datos de Oracle con la extensión oracle\$1fdw
Para acceder a una base de datos de Oracle desde su clúster de bases de datos de Aurora PostgreSQL puede instalar y utilizar la extensión `oracle_fdw`. Esta extensión es un contenedor de datos externos para bases de datos Oracle. Para obtener más información sobre la extensión, consulte la documentación de [oracle\$1fdw](https://github.com/laurenz/oracle_fdw).
La extensión `oracle_fdw` es compatible con Aurora PostgreSQL 12.7, (Amazon Aurora PostgreSQL versión 4.2) y versiones posteriores.
**Topics**
+ [Activación de la extensión oracle\$1fdw](#postgresql-oracle-fdw.enabling)
+ [Ejemplo: Usar un servidor externo vinculado a una Amazon RDS for Oracle Database](#postgresql-oracle-fdw.example)
+ [Trabajo con cifrado en tránsito](#postgresql-oracle-fdw.encryption)
+ [Comprensión y permisos de la vista pg\$1user\$1mappings](#postgresql-oracle-fdw.permissions)
## Activación de la extensión oracle\$1fdw
Para utilizar la extensión oracle\$1fdw, lleve a cabo el siguiente procedimiento.
**Para habilitar la extensión oracle\$1fdw**
+ Ejecute el siguiente comando con una cuenta que tenga los permisos `rds_superuser`.
```
CREATE EXTENSION oracle_fdw;
```
## Ejemplo: Usar un servidor externo vinculado a una Amazon RDS for Oracle Database
El siguiente ejemplo muestra el uso de un servidor externo vinculado a una base de datos de Amazon RDS for Oracle.
**Crear un servidor externo vinculado a una base de datos de RDS for Oracle**
1. Tenga en cuenta lo siguiente en la instancia de base de datos de RDS for Oracle:
+ punto de enlace
+ Puerto
+ Nombre de base de datos
1. Cree un servidor externo.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Otorgue uso a un usuario que no tenga permisos `rds_superuser`, por ejemplo `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Conéctese como `user1` y cree una asignación a un usuario de Oracle.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Cree una tabla externa vinculada a una tabla de Oracle.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Consulte la tabla externa.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
Si la consulta informa el siguiente error, verifique el grupo de seguridad y la lista de control de acceso (ACL) para asegurarse de que ambas instancias puedan comunicarse.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Trabajo con cifrado en tránsito
El cifrado de PostgreSQL a Oracle en tránsito se basa en una combinación de parámetros de configuración de cliente y servidor. Para obtener un ejemplo que utiliza Oracle 21c, consulte [About the Values for Negotiating Encryption and Integrity](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) en la documentación de Oracle. El cliente utilizado para oracle\$1fdw en Amazon RDS está configurado con `ACCEPTED`, lo que significa que el cifrado depende de la configuración del servidor de base de datos de Oracle y utiliza la biblioteca de seguridad de Oracle (libnnz) para cifrado.
Si su base de datos está en RDS for Oracle, consulte [Oracle Native Network Encryption](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html) para configurar el cifrado.
## Comprensión y permisos de la vista pg\$1user\$1mappings
El catálogo de PostgreSQL `pg_user_mapping` almacena la asignación desde un usuario Aurora PostgreSQL en el usuario de un servidor de datos externo (remoto). El acceso al catálogo está restringido, pero usted utiliza la vista `pg_user_mappings` para ver las asignaciones. A continuación, se muestra un ejemplo sobre cómo se aplican los permisos en una base de datos de Oracle de ejemplo, aunque esta información es válida también en general para cualquier contenedor de datos externo.
En el siguiente resultado, puede encontrar roles y permisos asignados a tres usuarios de ejemplo diferentes. Usuarios de `rdssu1` y `rdssu2` son miembros del rol `rds_superuser`, y el usuario `user1` no lo es. En el ejemplo se usa el metacomando `\du` de `psql` para enumerar los roles existentes.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
Todos los usuarios, incluidos los usuarios con privilegios `rds_superuser`, pueden ver sus propias asignaciones de usuarios (`umoptions`) en la tabla `pg_user_mappings`. Como se muestra en el siguiente ejemplo, cuando `rdssu1` intenta obtener todas las asignaciones de usuario, se genera un a pesar de los privilegios `rds_superuser` de `rdssu1`:
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
A continuación, se muestran algunos ejemplos:
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
Debido a las diferencias en la implementación de `information_schema._pg_user_mappings` y `pg_catalog.pg_user_mappings`, un `rds_superuser` que se crea manualmente requiere permisos adicionales para ver las contraseñas en `pg_catalog.pg_user_mappings`.
No requieren otros permisos para un `rds_superuser` para ver las contraseñas en `information_schema._pg_user_mappings`.
Los usuarios que no tienen el rol `rds_superuser` pueden ver contraseñas en `pg_user_mappings` solo en las condiciones que se describen a continuación:
+ El usuario actual es el usuario que se está asignando y es el propietario del servidor o tiene el privilegio de `USAGE` en él.
+ El usuario actual es el propietario del servidor, y la asignación es para `PUBLIC`.
# Uso de bases de datos de SQL Server con la extensión mysql\$1fdw
Puede utilizar la extensión de PostgreSQL `tds_fdw` para acceder a bases de datos compatibles con el protocolo de flujo de datos tabular (TDS), como bases de datos Sybase y Microsoft SQL Server. Este contenedor de datos externo le permite conectarse desde su clúster de bases de datos Aurora PostgreSQL a bases de datos que utilizan el protocolo TDS, incluido Amazon RDS for Microsoft SQL Server. Para obtener más información, consulte la documentación sobre [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw) en GitHub.
La extensión `tds_fdw` es compatible con las versiones 13.6 y posteriores de Aurora PostgreSQL.
## Configuración de la base de datos de Aurora PostgreSQL para utilizar la extensión mysql\$1fdw
En los procedimientos que siguen encontrará un ejemplo de configuración y uso de `tds_fdw` con un clúster de bases de datos Aurora PostgreSQL. Antes de poder conectarse a una base de datos SQL Server mediante `tds_fdw`, tiene que obtener los siguientes detalles de la instancia:
+ Nombre de host o del punto de conexión. Para instancias de RDS for MySQL encontrará los puntos de conexión con la consola. Elija la pestaña Conectividad y seguridad y busque en la sección “Punto de enlace y puerto”.
+ Número de puerto. El puerto 1433 es el predeterminado para Microsoft SQL Server.
+ Nombre de la base de datos. El identificador de la base de datos.
También deberá proporcionar acceso en el grupo de seguridad o en la lista de control de acceso (ACL) al puerto MySQL, 1433. Tanto como la instancia de base de datos RDS for MySQL Server necesitan poder acceder al puerto 1433. Si el acceso no está configurado correctamente, cuando intente consultar Microsoft SQL Server aparecerá el siguiente mensaje de error:
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**Para usar tds\$1fdw para conectarse a una base de datos de SQL Server**
1. Conéctese a su la instancia principal del clúster de bases de datos de Aurora PostgreSQL con una cuenta con rol `rds_superuser`:
```
psql --host=your-cluster-name-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. Instale la extensión `tds_fdw`.
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
Después de instalar la extensión en su clúster de bases de datos Aurora PostgreSQL , configure el servidor externo.
**Para crear el servidor externo**
Realice estas tareas en el clúster de bases de datos Aurora PostgreSQL con una cuenta que con privilegios `rds_superuser`.
1. Cree un servidor externo en el clúster de bases de datos Aurora PostgreSQL:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
Para acceder a datos no que sean ASCII en el lado de SQLServer, cree un enlace de servidor con la opción character\$1set en el clúster de base de datos de Aurora PostgreSQL:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. Conceda permisos a un usuario que no tenga los privilegios del rol `rds_superuser`, por ejemplo `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. Conéctese como user1 y, a continuación, cree una asignación para el usuario de SQL Server:
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. Cree una tabla externa vinculada a una tabla de SQL Server.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Consulte la tabla externa:
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### Uso de cifrado en tránsito para la conexión
La conexión de Aurora PostgreSQLa SQL Server utiliza cifrado en tránsito (TLS/SSL) según la configuración de la base de datos de SQL Server. Si SQL Server no está configurado para el cifrado, el RDS para el cliente PostgreSQL que realiza la solicitud a la base de datos de SQL Server vuelve a no ir cifrado.
Puede aplicar el cifrado para la conexión a RDS para instancias de base de datos de SQL Server configurando el parámetro `rds.force_ssl`. Para saber cómo, consulte [Requerir que las conexiones a la instancia de base de datos usen SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing). Para obtener más información sobre la configuración de SSL/TLS para RDS for SQL Server, consulte [Uso de SSL con una instancia de base de datos de Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html).