I'm using PostgreSQL 12. I have set up replication. And also set up the versioning history trigger for all the tables in the replica database to store audit history. But here in one of the tables, I'm storing the based64 content and it is not replicated properly in the replica database and it is stopping the database server.
It is throwing the error.
FATAL: the database system is in recovery mode
It is not happing in every case.
Base64(XML) Content in Master Database
Base64(XML) Content(InValid Conent) in Replica Database
Can anyone help me with why it is happening? Thanks in advance.
Below are the steps for configuration the replication:
Publication Databaase:
Creating the `REPLICA IDENTITY and assigning it to each table
Creating replication slot and publication :
select 1 from pg_create_logical_replication_slot('pubqablankdb','pgoutput')
create publication pubqablankdb for all tables
Subscription Database:
Creating Subscription:
CREATE SUBSCRIPTION subqablankdb CONNECTION 'host=1.1.1.1 port=5432 user=postgres password=xxxxx dbname=qablankdb' PUBLICATION pubqablankdb with (create_slot= false,slot_name = 'pubqablankdb', enabled = true);
Please see below the database info. (UTF8 encoding)
Master DB: qablankdb
Replica DB: auditlog
Related
I have a warm-standby postgres server and I store some information about the server itself in the database. So, the information kept in this table should be different between the primary and standby. However, once it is set to standby mode these values can no longer be updated. Is there any way to set specific tables/schemas to be writable while in standby mode?
One of several databases in a Postgres 10.15 cluster has been set to be a system database. The mechanism that caused this is unknown, though it may have happened at the same time that the database was converted to a template by updating the pg_database table. The pg_database table does not have a setting to control whether or not a database is a system database, however, and I cannot find any documentation describing how to set (or unset, which is what I really want to do) the system database flag.
The idea of a “system database” is foreign to PostgreSQL, it is an artifact of pgAdmin.
PostgreSQL does have the notion of a “template database”, that is a database that is intended to serve s template in CREATE DATABASE. You turn a database to a template database with
ALTER DATABASE some_db IS_TEMPLATE TRUE;
For such a database it is also a good idea to forbid connections, because you can only use a database as template if nobody else is connected to it:
ALTER DATABASE some_db ALLOW_CONNECTIONS FALSE;
I created an RDS Postgres instance. I'm new to RDS.
db host:
demodb.xxxuxxvxxxxx.us-east-2.rds.amazonaws.com
db identifier:
demodb
Every tutorial says to connect with this URL:
jdbc:postgresql://demodb.xxxuxxvxxxxx.us-east-2.rds.amazonaws.com:5432/demodb
but every time I do I get this error-
FATAl: database "demodb" does not exist.
I am able to connect using this:
jdbc:postgresql://demodb.xxxuxxvxxxxx.us-east-2.rds.amazonaws.com:5432/postgres
Now, while I was excited to connect after I used SQL workbench to create tables and insert data into those tables, a few hours later all my tables and data were deleted/wiped/dropped. Why would this happen? and How can I prevent it from happening in the future?
FATAl: database "demodb" does not exist.
demodb is db instance identifier. It is NOT the name of your database inside of PostgreSQL.
By default RDS PostgreSQL does not create a database for you. It seems to me that you haven't created an actual database when you setup your RDS PostgreSQL.
To create a database at RDS creation there is an option called Initial database name where you should specify the name of the database you want. Otherwise, no database is created, which is a default behavior:
I've recently implemented streaming replication and need to create a "report user" for the replica. This user will be used to access the database via ODBC to generate reports with.
On the slave (replica DB), It seems I cannot create new users. I also need to change the password of 'postgres' user on the slave. Here's what I've tried and the errors I get:
CREATE ROLE readaccess;
ERROR: cannot execute CREATE ROLE in a read-only transaction
\password postgres
ERROR: cannot execute ALTER ROLE in a read-only transaction
How can I create a new read only user for my replica?
How can I change the password of the user 'postgres' on the replica?
Note: I do realize that for a replica, you can (or should) only have read-only access.
Thank you.
As you have discovered, the replica is read-only anyway. So you have a few choices.
Just use any of your accounts from the primary. They will have the same permissions on the replica (except that they cannot change data).
Create a special user that only has 'select' permissions on the primary, and that user flow through to the replica.
As for having different passwords on the primary and replica, you can't. If that is a hard requirement for you, you'll have to look into "logical replication".
I'm following Realm Postgres Connector reference for syncing our Realm database with our Heroku PostgreSQL database: https://docs.realm.io/platform/using-synced-realms/server-side-usage/data-integration/postgres-connector#realm-data-adapter
It's working fine locally as I could connect to the PG local database withsuperuser role in order to use replication slots. However, superuser or replication roles cannot be set on Heroku PostgreSQL database, hence leading to the following PG error:
PGRES_FATAL_ERROR: ERROR: must be superuser or replication role to use replication slots
Does anybody already got Realm Postgres Connector working with a Heroku PG database? Or could think of a workaround?
Thanks for your help!
Lucas
Heroku support confirmed that there is currently no way to use replication roles:
Unfortunately, we do not allow creation of new replication slots by customers, as replication users are very privileged in Postgres, almost to the superuser level.
Hence I've decided to migrate to Amazon RDS. Here is a great article on how to perform such migration: https://www.lewagon.com/fr/blog/how-to-migrate-your-heroku-postgres-database-to-amazon-rds