AWS DMS unable to pick Postgre Replication Slot with custom name - postgresql

I am creating a DMS task to load data from RDS postgre to AWS s3. The DMS is creating a replication slot by default having a long alpha numeric slot name . Both Full load and CDC works fine with it .
I want to provide a useful name to the slot so that I can identify for which table it is being used for ?
Now when I try to create a slot with the a custom name using the following query :
select * FROM pg_create_logical_replication_slot('slotname', 'test_decoding');
It is getting created. But the active flag is false .
select * from pg_replication_slots
Is there any way to make it active ?
And provide the slotName in DMS Endpoint configuration in Extra connection attributes slotName=slotname

Related

AWS - Postgres Aurora RDS Cluster & `max_parallel_workers_per_gather`

I have an Aurora cluster on which I'm trying to globally disable parallel queries (so that I can safely lean on SET for configuration parameters to handle multi-tenant-edness...), but don't seem to be able to get AWS to cooperate.
I have both modified an existing parameter group, and tried an entirely new parameter group, both times setting max_parallel_workers_per_gather to 0 via the RDS console.
However, once the modification is complete, when I then connect to the database and query this with SHOW max_parallel_workers_per_gather, I find that the value is still set to the default of 2.
Am I doing something wrong? Is there another way to set this parameter globally?
Thanks!
This query should tell you where the setting comes from:
SELECT setting, source, sourcefile, sourceline
FROM pg_settings
WHERE name = 'max_parallel_workers_per_gather';

Can I configure AWS RDS to only stream INSERT operations to AWS DMS?

My requirement is to stream only INSERTs on a specific table in my db to a Kinesis data stream.
I have configured this pipeline in my AWS environment:
RDS Postgres 13 -> DMS (Database Migration Service) -> KDS (Kinesis Data Stream)
This setup works correctly but it processes all changes, even UPDATEs and DELETEs, on my source table.
What I've tried:
Looking for config options in the Postgres logical decoding plugin. DMS uses the test_decoding PG plugin which does not accept options to include/exclude data changes by operation type.
Looking at the DMS selection and filtering rules. Still didn't see anything that might help.
Of course I could simply ignore records originated from non-INSERT operations in my Kinesis consumer, but this doesn't look like a cost-efficient implementation.
Is there any way to meet my requirements using these AWS services (RDS -> DMS -> Kinesis)?
Well DMS does not have this capability .
If you want only INSERT to be send to Kinesis in that case you can have a lambda function on every INSERT of RDS .
Lambda function can be configured as trigger for INSERT .
You can invoke lambda only for INSERT and write to Kinesis directly .
Cost wise also this will be less .
In DMS you are paying for Replication instance even when not in use .
For detailed reference Stream changes from Amazon RDS for PostgreSQL using Amazon Kinesis Data Streams and AWS Lambda

AWS RDS Postgres: WAL_LEVEL not set to 'logical' after changing rds.logical_replication = 1

I am in the process of setting up Debezium to work with AWS Aurora Postgres (postgres version 12.6).
For Debezium to work, the WAL (Write-ahead-logging) must be set to 'logical' and not 'replica'.
On AWS, this would require a DBA to set the rds.logical_replication parameter in the parameter group to be set to 1.
The above was done. The database instance was restarted.
To verify that the WAL level was changed to 'logical', I ran the following query:
show wal_level.
However, after running this query in postgres on the target database the result showed replica.
I further looked at the log events in the AWS management console and I saw these log events.
Would anyone have an idea why this might be? There is another environment where we were able to successfully set the rds.logical_replication to 1 and following a database restart, the WAL was set to logical. But for our main environment this is not the case. Looking at the parameter groups, between these two environments, they are the same.
Any help/ advice is appreciated. thanks.
Ok after contacting the AWS support I got the information that the parameter "rds.logical_replication=1" is only active on the instance that has the Writer role (open for read-write). When you set this parameter you will have to use the writer instance for logical replication. You can connect to the writer instance either via Cluster endpoint (recommended) or instance endpoint.
I was checking the read-only instance with SHOW wal_level; but in fact it was set on the read/write instance !!!

How to set query timeout time in RDS postgres

Can we set the query timeout option in the AWS Postgres instance?
I know we can do it locally in the configuration file if we have a local setup but not sure about AWS RDS.
Any help would be appreciated because due to the above issue CPU utilization is increasing.
You can achieve it by creating Parameter groups in AWS RDS
Please follow below steps.
Go to AWS Console -> Amazon RDS
Select Parameter Group to create parameter group
select appropriate version of Postgres,provide group name and click on create.
Now select the created Parameter Group and search the parameter as statement_timeout
Click on Edit Parameter button and set the value inside the Values box
Save changes.
Now while creating or modifying the database select newly created parameter group.

AWS DMS - Scheduled DB Migration

I have Postgresql db in RDS. I need to fetch data from a bunch of tables in postgresql db and push data into a S3 bucket every hour. I only want the delta changes (any new inserts / updates) to be sent in the hourly. Is it possible to do this using DMS or is EMR a better tool for performing this activity?
You can create an automated environment of migration data from RDS to S3 using AWS DMS (Data Migration Service) tasks.
Create a source endpoint (reading your RDS database - Postgres, MySQL, Oracle, etc...);
Create a target endpoint using S3 as an engine endpoint (read it: Using Amazon S3 as a Target for AWS Database Migration Service);
Create a replication instance, responsible to make a bridge between source data and target endpoint (you will only pay while processing);
Create a database migration task using the option 'Replication data change only' on migration type field;
Create a cron lambda, which starts a DMS task, with stack Python following these instructions of this articles Lambda with scheduled events e Start DMS tasks with boto3 in Python.
Connecting these resources above you may can have what you want.
Regards,
Renan S.