I have been trying to implement database clustering and replication in timescaleDB. I have done the setup for replication, then the primary database is replicated to the replica node.
But in the replica database, I can perform the read-only query. I could not run queries such as create, insert, or update.
How can I make a replica server writable?
database version: 12.12
config in the primary database
synchronous_commit = off
wal_level = replica
max_replication_slots = 150
listen_addresses = '*'
I have followed the following document for database replication
https://docs.timescale.com/timescaledb/latest/how-to-guides/replication-and-ha/configure-replication/
Related
I have a database hosted in my companies local data centre (source) and another cloud-hosted database (AWS RDS Postgres Online data store)
The local database (on-prem) is updated on an intraday basis (every 1-2 hours), how can I ensure that I move the new data to the RDS Database as soon as changes/updates occur in the local source database (we need this updated data from source to run specific processes/business logic on the RDS database as soon as changes occur in the source databases).
Would AWS DMS or AWS Kinesis be sufficient for this use case?
Try to implement native replication from Postgre, it would be the best method https://hevodata.com/learn/postgresql-streaming-replication/
I need a database, which is idle most of the time, because it is a test db. The devs normally use their local DB. Is there some function like: when 30 minutes of inactivity -> then stop db
When you are talking about an RDBMS, then there is Aurora Serverless, with either MySQL or PostgreSQL Compatibility.
You can configure it to scale-down to zero "capacity units" after a certain period of inactivity.
One key difference between an Aurora Serverless DB cluster and a provisioned DB instance is that with a Aurora Serverless DB cluster you cannot directly make the DB endpoint publicly accessible (from the Internet).
I'm trying to create an Aurora read replica from a RDS MySQL database, but I'm getting the following error:
You must enable backups on the master DB instance in order to set up DB instance to DB cluster replication...
I double checked the source instance and I already have backups enabled.
What else could be the problem?
It turns out that the problem was that my Backup retention period was set to 0 days.
I am having an AWS RDS Aurora PostgreSQL cluster with four instances with a Multi-AZ deployment serving in Production. Encryption-at-rest hasn't been enabled on this cluster. Now I have to enable the encryption on this existing cluster. AWS docs suggest me to create a snapshot of that cluster and then restore the cluster again with the encryption enabled this time. Ref: Here
Since my cluster is serving in production and no downtime or I/O suspension is acceptable to me. Here are some questions that I would like to get answered before I plan about encrypting the existing cluster:
Is there any downtime during the creation of the snapshot assuming there is a lot of data and a snapshot will take time.
What about the new data that is being written on to the database during the snapshot creation? Is the snapshot creation real-time or I will lose my new data during the time till the snapshot is being taken?
Is this the only way for me to enable encryption on the production cluster knowing that it will result in some database outage?
There is a way to encrypt your AWS RDS Amazon Aurora with PostgreSQL compatibility Cluster with no or minimum downtime, but it will take a bit of effort.
You need to take the following steps:
For the source DB, you have to take snapshot.
Then copy that snapshot, and check Enable Encryption and select Default Encryption Key or select your Custom AWS KMS CMK, now you have an encrypted copy of your DB snapshot.
Restore this encrypted snapshot to the new DB instance, and you can enable Multi-AZ and add Read Replicas now or modify them after migration.
Now you have two DB instances Encrypted and Unencrypted, but the data mismatched as it is a production database.
We will use AWS DMS to make synchronous replication of data, or ou can use PostgreSQL logical replication with Aurora instead of AWS DMS, it will be better, both will works.
Go to AWS DMS console, create an AWS DMS task.
For migration type, choose Migrate existing data and replicate ongoing changes.
For target table preparation mode, choose Truncate.
Under Advanced Task Settings, enable the awsdms_status table if you want to verify replication status.
Run the migration task and wait until all the records are updated. AWS DMS will then determine the size of the data to migrate.
Then, you need to verify the data in the Encrypted DB instance after migration is the same as the Unencrypted DB instance.
Check replication status in AWS DMS, by checking the migration task and awsdms_status.
You can now route traffic to the new endpoint.
For a smooth cutover, use Amazon Route 53 to route traffic by changing the DNS TTL to a short value, and eventually replacing the endpoint names in Route 53.
Now replying to your questions,
Is there any downtime during the creation of the snapshot assuming there is a lot of data and a snapshot will take time.
According to you cluster setup, you are running a Multi-AZ deployment, automated backups and DB Snapshots are simply taken from the standby to avoid I/O suspension on the primary. Please note that you may experience increased I/O latency (typically lasting a few minutes) during backups for both Single-AZ and Multi-AZ deployments.
What about the new data that is being written on to the database during the snapshot creation? Is the snapshot creation real-time or I
will lose my new data during the time till the snapshot is being
taken?
You will lose your data written after the snapshot has been taken, so you will use AWS DMS to replicate synchronous data to your encrypted DB instances.
Is this the only way for me to enable encryption on the production cluster knowing that it will result in some database outage?
Yes this is the only way, but it will result in no or little downtime.
When I restore a MySQL snapshot, I'm given the option to make the new instance Multi-AZ. However for some reason when I restore to Aurora, the "Multi-AZ Deployment" selection is disabled.
I thought possibly this meant it was automatically enabled. However when I go to the running instance details, it specifically lists Multi-AZ: "No".
Is there something I'm missing? Is there some other step I need to do to make Aurora Multi-AZ?
Multi-AZ doesn't mean the same thing in Aurora as it does for MySQL and MariaDB. With Aurora, any replica in the cluster can take over for the master on failure (though the selection is based on priority, so it isn't just a randomly selected replica, if there is more than one replica), and the storage is already/always multi-AZ in Aurora because that's a core part of the Aurora design. So, Aurora can be "converted" to Multi-AZ.
Apparently, that's the only way it is done when creating an Aurora instance from a snapshot, based on this:
You can migrate a DB snapshot of an Amazon RDS MySQL DB instance to create an Aurora DB cluster.
...
You can migrate either a manual or automated DB snapshot. After the DB cluster is created, you can then create optional Aurora Replicas.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.RDSMySQL.html
If you create a multi-AZ Aurora cluster without a snapshot, that's all that happens -- a master and a replica are created. In that case, you can actually delete the replica and make it non-multi-AZ, which is a different process than what's involved with MySQL or MariaDB.
"Create a cluster" -- as used in the quote, above -- is a potentially confusing term, since you would naturally assume a cluster means two or more, but in fact an Aurora cluster can technically be a "cluster" of just one instance. Every Aurora instance is part of exactly one cluster. One instance is the primary (master) and any additional instances are replicas.
If the DB cluster doesn't contain any Aurora Replicas, then the primary instance is recreated during a failure event.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Managing.html#Aurora.Managing.FaultTolerance