PostgreSQL replication commands

 

How to get the master database details from replica server?

using a veiw pg_stat_wal_receiver we can get the master database details.

 

postgres=# select * from pg_stat_wal_receiver;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 29104
status                | streaming
receive_start_lsn     | 0/9000000
receive_start_tli     | 6
written_lsn           | 0/9000520
flushed_lsn           | 0/9000520
received_tli          | 6
last_msg_send_time    | 2024-03-25 12:16:07.179751-04
last_msg_receipt_time | 2024-03-25 12:16:07.304224-04
latest_end_lsn        | 0/9000520
latest_end_time       | 2024-03-25 12:12:37.136572-04
slot_name             | pgautofailover_standby_2
sender_host           | master01.localdomain
sender_port           | 5432
conninfo              | user=pgautofailover_replicator passfile=/var/lib/pgsql/.pgpass channel_binding=prefer dbname=replication host=master01.localdomain port=5432 application_name=pgautofailover_standby_2 fallback_application_name=walreceiver sslmode=prefer sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres target_session_attrs=any


 

How to check the replication status?

 using pg_stat_replication

 

postgres=# select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 22386
usesysid         | 16411
usename          | pgautofailover_replicator
application_name | pgautofailover_standby_2
client_addr      | 172.20.10.102
client_hostname  | rep01.localdomain
client_port      | 47196
backend_start    | 2024-03-25 12:12:26.20471-04
backend_xmin     |
state            | streaming
sent_lsn         | 0/9000520
write_lsn        | 0/9000520
flush_lsn        | 0/9000520
replay_lsn       | 0/9000520
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 1
sync_state       | quorum
reply_time       | 2024-03-25 12:15:07.457995-04
-[ RECORD 2 ]----+------------------------------
pid              | 22462
usesysid         | 16411
usename          | pgautofailover_replicator
application_name | pgautofailover_standby_3
client_addr      | 172.20.10.103
client_hostname  | rep02.localdomain
client_port      | 43241
backend_start    | 2024-03-25 12:12:51.295878-04
backend_xmin     |
state            | streaming
sent_lsn         | 0/9000520
write_lsn        | 0/9000520
flush_lsn        | 0/9000520
replay_lsn       | 0/9000520
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 1
sync_state       | quorum
reply_time       | 2024-03-25 12:15:11.523423-04


 

How to monitor replication confilcts in Standby database?

By using the view pg_stat_database_conflicts;

 

postgres=# select * from pg_stat_database_conflicts;
 datid |  datname  | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock
-------+-----------+------------------+------------+----------------+-----------------+----------------
 14487 | postgres  |                0 |          0 |              0 |               0 |              0
 16384 | autodb    |                0 |          0 |              0 |               0 |              0
     1 | template1 |                0 |          0 |              0 |               0 |              0
 14486 | template0 |                0 |          0 |              0 |               0 |              0
(4 rows)

 

Info: The following parameters deals with replication conflicts.


# standby end   
hot_standby_feedback = on
hot_standby = off

max_standby_streaming_delay
max_standby_archive_delay



# master end
vacuum_truncate = off

postgres=# show max_standby_streaming_delay ;
 max_standby_streaming_delay
-----------------------------
 30s
(1 row)

postgres=# show max_standby_archive_delay;
 max_standby_archive_delay
---------------------------
 30s
(1 row)

 



Comments

Post a Comment

Popular posts from this blog

Auditing in Oracle database

Unified Auditing: Oracle Database 12c Release 1 introduces a new auditing feature called Unified Auditing (12.1). Oracle Unified Auditing modifies the database's fundamental auditing capabilities. In earlier versions of Oracle, each component has its own audit trail. With unified auditing, all auditing is compiled into a single repository and view. Due to the fact that all audit data is now in a single location and a single format, there is a double simplification as a result. This data is made available in a consistent format in the UNIFIED AUDIT TRAIL data dictionary view, which is made possible by the unified audit trail, which is stored in a read-only table in the AUDSYS schema in the SYSAUX tablespace.  DBAs can build audit rules and then assign them to various users using Oracle 12c Unified Auditing, which has the same advantages as giving users varying system capabilities based on their responsibilities. The unified_audit_trail database will contain all of the audit records....
Read more

Tuples in Python

 Tuples Basically Tuples in Python are very similar to Lists, but, Tuples are immutable which means that they can not be modified/changed. We generally use Tuples to make sure the values are not changed like, dates, Year, and days of the week or dates on a Calendar.  Creating a Tuple: >>> my_t1=(1,2,3) >>> my_t2=('one','two','three') >>> my_t1 (1, 2, 3) >>> my_t2 ('one', 'two', 'three') -- check the length of tupple: >>> len(my_t1) 3 >>> len(my_t2) 3 -- Tuples can have mixed objects as like Lists. >>> my_t3=(1,'two',3,'four') >>> my_t3 (1, 'two', 3, 'four') -- indexing with tuples  >>> my_t3=(1,'two',3,'four') >>> my_t3[2] 3 Immutable Tuples We can not modify the value. Here is the example: >>> my_t3=(1,'two',3,'four') >>> my_t3[2]=4 Traceback (most recent call last):  ...
Read more

rs.stepDown() in MongoDB replication

It instructs the primary of the replica set to become a secondary. After the primary steps down,the eligible secondaries will hold an election for primary. Generally, the rs.stepDown() does not immediately step down the primary. If no electable secondaries are up to date with the primary, the primary waits up to secondaryCatchUpPeriodSecs (by default 10 seconds)  for a secondary to catch up. Once an electable secondary is available, the method steps down the priamry.  Once stepped down, the original primary becomes a secondary and is ineligible from becoming primary again for the remainder of time specified by stepDownSecs. The rs.stepDown() method attempts to terminate long-running user's operations that block the primary from stepping down, such as an index build, a write operation, or a map-reduce job. Syntax: rs.stepDown(stepDownSecs, secondaryCatchUpPeriodSecs)
Read more