RE: Barman 2.3 errors - Mailing list pgsql-general

From GALLIANO Nicolas
Subject RE: Barman 2.3 errors
Date
Msg-id B0A9AE76BE13F049BD6E9EB7DEC2D52C01287D8BC2@CNMB03WVP.core-res.rootcore.local
Whole thread Raw
In response to RE: Barman 2.3 errors  ("Ahmed, Nawaz" <Nawaz@fast.au.fujitsu.com>)
Responses RE: Barman 2.3 errors
List pgsql-general

Hi

 

1/ thanks for your answer

2/ it’ right … the barman support list is better … sorry

3/ i’ve verified the pg replication slot :

 

postgres@postgres# SELECT slot_name, active, restart_lsn FROM pg_replication_slots WHERE slot_type = 'physical' AND slot_name = 'barman';

slot_name | active | restart_lsn

-----------+--------+-------------

barman    | t      | 1/7B000840

 

 

4/ i’ve tried this :

 

-          Receive-wal process not running :

barman@tcgipocgresql:/var/log/barman [2018/02/13-09:23:53]

$ps -ef |grep receive-wal

barman   48067  4398  0 09:58 pts/0    00:00:00 grep --color=auto receive-wal

 

-          Receive-wal process failed start :

$barman receive-wal tcgepg96ddm

Starting receive-wal for server tcgepg96ddm

ERROR: ArchiverFailure:replication slot 'barman' is already in use

 

-          Receive-wal reset :

$barman receive-wal --reset tcgepg96ddm

Starting receive-wal for server tcgepg96ddm

Resetting receive-wal directory status

Removing status file /var/lib/barman/tcgepg96ddm/streaming/00000001000000010000007B.partial

 

-          Switch-xlog :

$barman switch-xlog tcgepg96ddm

The WAL file 00000001000000010000007B has been closed on server 'tcgepg96ddm'

 

Then if i try when the replication slot is not active the receive-wal crash and i have this error :

 

$barman receive-wal tcgepg96ddm

Starting receive-wal for server tcgepg96ddm

EXCEPTION: 'utf8' codec can't decode byte 0xe0 in position 47: invalid continuation byte

See log file for more details.

 

And in the log i still have the UnicodeDecodeError …

 

On a post (https://sourceforge.net/p/pgbarman/tickets/88/)  i’ve found that it’s a barman bug with a workaround … but the solution don’t work for me ...

I’m still looking for a solution L

 

Thanks for your help

Have a good day

nicolas

 

 

 

 

 

De : Ahmed, Nawaz [mailto:Nawaz@fast.au.fujitsu.com]
Envoyé : mardi 13 février 2018 08:07
À : GALLIANO Nicolas <Nicolas.GALLIANO@dsi.cnrs.fr>; pgsql-general@postgresql.org
Objet : RE: Barman 2.3 errors

 

 

Hi Nicolas,

 

I would like to take stab at this one, as i had recently worked on a demo of barman. But like Michael Paquier said, it is better to check the information i provide and the situation you are facing with the maintainers of the project. Here is what i found.

 

The first thing is to check if you can see the replication slot named "barman" created on the target database using the below command. It should return a slot named "barman" with the slot_type as "physical". The "replication slot: OK" line of the check command shows the slot is available, however, please double check if it is true with the below query.

 

 

select * from pg_replication_slots;

 

 

Now let us target the line "WAL archive: FAILED", I faced this issue when i had killed the "receive-wal" process and restarted it.  First look for the receive-wal process with the ps command

 

ps -ef|grep receive-wal

 

if it is not running then start it up in the background using the command

 

$ barman receive-wal tcgepg96ddm &

 

If the receive-wal process is running but you still face that error in the check command, then I suggest you switch the xlog using the below command.

 

$ barman switch-xlog tcgepg96ddm

 

if the above command fails to switch the xlog, then try to force it with the below command.

 

$ barman switch-xlog --force tcgepg96ddm

 

if you still cannot get it to work, then try to reset the status of the receive-wal process using the --reset option as below.

 

$ barman receive-wal --reset tcgepg96ddm

 

 

If you can successfully run the above reset command, then try to switch the log file  and run the check command again to see if everything looks fine.

 

$ barman switch-xlog tcgepg96ddm

 

 

Hope that helps, again, these are the steps i had taken to resolve a similar issue. You might still want to get in touch with the project maintainers about the validity of the above commands.

 

 

Best Regards,

 

Nawaz Ahmed
Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd

14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9027
Nawaz@fast.au.fujitsu.com
fastware.com.au


 

From: GALLIANO Nicolas [mailto:Nicolas.GALLIANO@dsi.cnrs.fr]
Sent: Tuesday, 13 February 2018 2:23 AM
To: pgsql-general@postgresql.org
Subject: Barman 2.3 errors

 

Hi,

 

I’m trying to backup a remote DB (9.6.6) using barman 2.3 but backup failed start.

In barman.log i’ve such errors :

 

2018-02-12 16:18:23,852 [57691] barman.server ERROR: Check 'replication slot' failed for server 'tcgepg96ddm'

2018-02-12 16:18:23,857 [57691] barman.server ERROR: Check 'receive-wal running' failed for server 'tcgepg96ddm'

2018-02-12 16:18:30,815 [57779] barman.wal_archiver INFO: No xlog segments found from streaming for tcgepg96ddm.

2018-02-12 16:18:30,824 [57781] barman.server INFO: Starting receive-wal for server tcgepg96ddm

2018-02-12 16:18:30,905 [57781] barman.wal_archiver INFO: Synchronous WAL streaming for barman_receive_wal: True

2018-02-12 16:18:30,906 [57781] barman.wal_archiver INFO: Activating WAL archiving through streaming protocol

2018-02-12 16:18:30,922 [57781] barman.cli ERROR: 'utf8' codec can't decode byte 0xe0 in position 47: invalid continuation byte

See log file for more details.

Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/barman/cli.py", line 1126, in main

    p.dispatch(pre_call=global_config)

  File "/usr/lib/python2.7/site-packages/argh/helpers.py", line 55, in dispatch

    return dispatch(self, *args, **kwargs)

  File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 174, in dispatch

    for line in lines:

  File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 277, in _execute_command

    for line in result:

  File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 231, in _call

    result = function(namespace_obj)

  File "/usr/lib/python2.7/site-packages/barman/cli.py", line 792, in receive_wal

    server.receive_wal(reset=args.reset)

  File "/usr/lib/python2.7/site-packages/barman/server.py", line 1708, in receive_wal

    archiver.receive_wal(reset)

  File "/usr/lib/python2.7/site-packages/barman/wal_archiver.py", line 751, in receive_wal

    receive.execute()

  File "/usr/lib/python2.7/site-packages/barman/command_wrappers.py", line 418, in execute

    self.pipe_processor_loop(processors)

  File "/usr/lib/python2.7/site-packages/barman/command_wrappers.py", line 484, in pipe_processor_loop

    eof = stream.process()

  File "/usr/lib/python2.7/site-packages/barman/command_wrappers.py", line 82, in process

    self._buf += data.decode('utf-8')

  File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode

    return codecs.utf_8_decode(input, errors, True)

UnicodeDecodeError: 'utf8' codec can't decode byte 0xe0 in position 47: invalid continuation byte

2018-02-12 16:18:32,373 [58491] barman.server ERROR: Check 'WAL archive' failed for server 'tcgepg96ddm'

2018-02-12 16:18:32,468 [58491] barman.wal_archiver INFO: Synchronous WAL streaming for barman_receive_wal: True

2018-02-12 16:18:32,485 [58491] barman.server ERROR: Check 'receive-wal running' failed for server 'tcgepg96ddm'

 

 

My remote Db server conf is :

 

[myclient]

conninfo = host=myclient user=barman dbname=dbclient

streaming_conninfo = host= myclient user=streaming_barman

backup_method = postgres

streaming_backup_name = barman_streaming_backup

streaming_archiver = on

slot_name = barman

 

A barman check gives :

 

$barman check tcgepg96ddm

Server tcgepg96ddm:

        WAL archive: FAILED (please make sure WAL shipping is setup)

        PostgreSQL: OK

        is_superuser: OK

        PostgreSQL streaming: OK

        wal_level: OK

        replication slot: OK

        directories: OK

        retention policy settings: OK

        backup maximum age: OK (no last_backup_maximum_age provided)

        compression settings: OK

        failed backups: OK (there are 0 failed backups)

        minimum redundancy requirements: OK (have 0 backups, expected at least 0)

        pg_basebackup: OK

        pg_basebackup compatible: OK

        pg_basebackup supports tablespaces mapping: OK

        pg_receivexlog: OK

        pg_receivexlog compatible: OK

        receive-wal running: FAILED (See the Barman log file for more details)

        archiver errors: OK

 

 

Have you ever had same problem with barman ?

Thanks for you help.

nicolas

Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.

 

Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.

 

If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.au.fujitsu.com

Attachment

pgsql-general by date:

Previous
From: Luis Carril
Date:
Subject: Re: Trying to the behavior of a parallel query with with a change inthe transaction isolation mode
Next
From: Robert Zenz
Date:
Subject: Prepared statements (PREPARE and JDBC) are a lot slower than "normal"ones.