2ndQuadrant is now part of EDB

Bringing together some of the world's top PostgreSQL experts.

2ndQuadrant | PostgreSQL
Mission Critical Databases
  • Contact us
  • EN
    • FR
    • IT
    • ES
    • DE
    • PT
  • Support & Services
  • Products
  • Downloads
    • Installers
      • Postgres Installer
      • 2UDA – Unified Data Analytics
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
  • Postgres Learning Center
    • Webinars
      • Upcoming Webinars
      • Webinar Library
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Blog
    • Training
      • Course Catalogue
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
    • Books
      • PostgreSQL 11 Administration Cookbook
      • PostgreSQL 10 Administration Cookbook
      • PostgreSQL High Availability Cookbook – 2nd Edition
      • PostgreSQL 9 Administration Cookbook – 3rd Edition
      • PostgreSQL Server Programming Cookbook – 2nd Edition
      • PostgreSQL 9 Cookbook – Chinese Edition
    • Videos
    • Events
    • PostgreSQL
      • PostgreSQL – History
      • Who uses PostgreSQL?
      • PostgreSQL FAQ
      • PostgreSQL vs MySQL
      • The Business Case for PostgreSQL
      • Security Information
      • Documentation
  • About Us
    • About 2ndQuadrant
    • 2ndQuadrant’s Passion for PostgreSQL
    • News
    • Careers
    • Team Profile
  • Blog
  • Menu Menu
You are here: Home1 / Blog2 / Florins PlanetPostgreSQL3 / Support for PostgreSQL’s System identifier in Barman
Support for PostgreSQL’s System identifier in Barman
Florin Irion

Support for PostgreSQL’s System identifier in Barman

January 9, 2020/3 Comments/in Florins PlanetPostgreSQL /by Florin Irion

The latest Barman 2.10 release introduces support for the system identifier of a PostgreSQL instance.
In this article, I will answer a few questions explaining what a system identifier is and why it is a good thing that Barman uses it.

What is the PostgreSQL system identifier?

PostgreSQL gives a unique system identifier to every database server (instance) when it is initialized to ensure it matches up WAL files with the installation that produced them.
When you make a physical backup the system identifier will be preserved also if a new instance will be created from that backup either if it’s a standby or not.

How can I retrieve the system identifier?

To retrieve the system identifier on a PostgreSQL instance, you can use `pg_controldata` or query the database.

pg_controldata

The `pg_controldata` command will return many pieces of information of the cluster and also the system identifier.

-shell$ pg_controldata
...
Database system identifier: 6771759591265590184
...

PostgreSQL query

One other way is to query directly the database.
Using the function pg_control_system() we are able to get, among other information, also the system_identifier.

-shell$ psql -c "SELECT system_identifier FROM pg_control_system()"
system_identifier
---------------------
6771759591265590184

PostgreSQL query through streaming replication protocol

PostgreSQL streaming replication protocol has one command called IDENTIFY_SYSTEM to return the system identifier. The following example query will return the system identifier, the current timeline ID, the current WAL flush location, and the connected database, where applicable:

-shell$ psql replication=1 -c "IDENTIFY_SYSTEM"
systemid            | timeline | xlogpos    | dbname
--------------------+----------+------------+--------
6771759591265590184 |        1 | 0/A04A38D0 |

How does Barman use the system identifier?

Barman stores the system identifier in the server directory (identity.json) when it performs the first backup. Barman compares the system identifier that it gets from the active connections (standard and replication) with the stored value when performing the check command.

It will also check that the system identifier is the same for both replication and standard connections, throwing an error if they are not:

error: is the streaming DSN targeting the same server of the PostgreSQL connection string?

This removes the risk of receiving WAL files from two different servers and risk to invalidate the backup.

What happens if the system identifier changes?

If the System Identifier is a unique identifier for the instance then why should it change?
Well, one use case of changing the system identifier could be when you use pg_upgrade to use a new PostgreSQL major version.
If that happens, then the Barman’s `check` command will throw an error, preventing any further backups.

-shell$ barman backup all
ERROR: Impossible to start the backup. Check the log for more details, or run 'barman check server_name'

The `check` command explicitly warns about the incongruence with the system identifier that Barman has stored in the identity file with the one that comes from the new PostgreSQL server.

-shell$ barman check all
...
systemid coherence: FAILED (the system Id of the connected PostgreSQL server changed, stored in "/var/lib/barman//identity.json")
...

You need to treat the new upgraded instance as if it were a new server to backup.

How can I retrieve the system identifier from Barman?

Via `diagnose`

The most thorough way to do it in Barman is with the `barman diagnose` command. It will print information on what the system identifier is for:

  • streaming connection
  • PostgreSQL standard connection
  • every backup of every configured server
-shell$ barman diagnose
...
backup
-> "systemid": "6771759591265590184",
...
status
-> "postgres_systemid": "6771759591265590184",
-> "streamingsystemid": "6771759591265590184",
...

Per-server information

You can also verify the system identifier for a specific server.
Use the `barman show-server SERVER_NAME` command to retrieve it.

-shell$ barman show-server
postgres_systemid: 6771759591265590184
streaming_systemid: 6771759591265590184

Per-backup information

Similarly to servers, you can also find the system identifier for a given backup:

-shell$ barman show-backup node1 20191219T163212
Backup 20191219T163212:
Server Name :
System Id : 6771759591265590184
...

Conclusions

The last question is: Why do I need to understand all this?

As I said at the beginning of this article, Barman from the 2.10 release introduces support for the system identifier. It becomes more robust and will save us from errors when we didn’t think of, like backing up the WAL files of an upgraded server where you have the ones for the old version one.
Barman will take care of everything and it will explicitly tell us what the problem is.
This article helps us understand what barman is “telling” us in the logs and in the check command regarding the system identifier so we can investigate both on PostgreSQL and Barman side.

And remember, upgrade barman to the latest version!

Please visit  www.pgbarman.org for more information.

Tags: backup, Barman, disaster recovery, DR, identfy, identifier, pgbarman, PostgreSQL, system, system_identifier, unique
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
3 replies
  1. Emeric Hunter
    Emeric Hunter says:
    March 12, 2020 at 2:27 pm

    Could you elaborate on : “You need to treat the new upgraded instance as if it were a new server to backup.” When the system Id changes ?

    Reply
    • Florin Irion
      Florin Irion says:
      March 22, 2020 at 10:01 am

      When you upgrade an instance with `pg_upgrade`, this one changes the system_identifier.
      From a backup point of view, you need to treat this one as if it was a completely different instance.
      You can not use the old backups, so you need to configure it on the barman server as a new instance.

      Reply
      • Tiago Dantas
        Tiago Dantas says:
        August 13, 2020 at 11:17 pm

        Hi Florin, could you tell me what I need to do for the old barman server after the upgrade?
        Setting archiver and streaming_archiver in its conf file to off is enough? If I remove the conf file I can’t use the old backups.

        Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search

Get in touch with us!

Recent Posts

  • Random Data December 3, 2020
  • Webinar: COMMIT Without Fear – The Beauty of CAMO [Follow Up] November 13, 2020
  • Full-text search since PostgreSQL 8.3 November 5, 2020
  • Random numbers November 3, 2020
  • Webinar: Best Practices for Bulk Data Loading in PostgreSQL [Follow Up] November 2, 2020

Featured External Blogs

Tomas Vondra's Blog

Our Bloggers

  • Simon Riggs
  • Alvaro Herrera
  • Andrew Dunstan
  • Craig Ringer
  • Francesco Canovai
  • Gabriele Bartolini
  • Giulio Calacoci
  • Ian Barwick
  • Marco Nenciarini
  • Mark Wong
  • Pavan Deolasee
  • Petr Jelinek
  • Shaun Thomas
  • Tomas Vondra
  • Umair Shahid

PostgreSQL Cloud

2QLovesPG 2UDA 9.6 backup Barman BDR Business Continuity community conference database DBA development devops disaster recovery greenplum Hot Standby JSON JSONB logical replication monitoring OmniDB open source Orange performance PG12 pgbarman pglogical PG Phriday postgres Postgres-BDR postgres-xl PostgreSQL PostgreSQL 9.6 PostgreSQL10 PostgreSQL11 PostgreSQL 11 PostgreSQL 11 New Features postgresql repmgr Recovery replication security sql wal webinar webinars

Support & Services

24/7 Production Support

Developer Support

Remote DBA for PostgreSQL

PostgreSQL Database Monitoring

PostgreSQL Health Check

PostgreSQL Performance Tuning

Database Security Audit

Upgrade PostgreSQL

PostgreSQL Migration Assessment

Migrate from Oracle to PostgreSQL

Products

HA Postgres Clusters

Postgres-BDR®

2ndQPostgres

pglogical

repmgr

Barman

Postgres Cloud Manager

SQL Firewall

Postgres-XL

OmniDB

Postgres Installer

2UDA

Postgres Learning Center

Introducing Postgres

Blog

Webinars

Books

Videos

Training

Case Studies

Events

About Us

About 2ndQuadrant

What does 2ndQuadrant Mean?

News

Careers 

Team Profile

© 2ndQuadrant Ltd. All rights reserved. | Privacy Policy
  • Twitter
  • LinkedIn
  • Facebook
  • Youtube
  • Mail
Adventure in programming languages and simple statistics BDR Latest Features & Updates Webinar Webinar: BDR – Latest Features & Updates [Follow Up]
Scroll to top
×