Re: New Slave - timeline ERROR

Поиск
Список
Период
Сортировка
От drum.lucas@gmail.com
Тема Re: New Slave - timeline ERROR
Дата
Msg-id CAE_gQfWTBNvo5G1diPaY6Ae2SVoEo2tQ2HgiJdU6OXz=KPug+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New Slave - timeline ERROR  ("drum.lucas@gmail.com" <drum.lucas@gmail.com>)
Список pgsql-general
Hi guys..
I started a new PG_BASEBACKUP and it's working now..

The problem was the line: standby_mode = on on the recovery.conf  on the STANDBY server.

After the basebackup, I comented this line and started the postgreSQL. BUT, you shouldn't  do that.

On the last time I didn't  comment and it worked. 

Thank you!



Lucas Possamai


On 10 January 2016 at 19:22, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:
What is the --pgdata=- in your original command? Are you perhaps in the wrong directory and not getting all the required files?

I run the pg_basebackup from the Slave on /var/lib/pgsql/9.2/data.
So I'm not in the wrong directory...

I'm out of fresh ideas. The rsync command is what I would go with, given that I can't think of any other commands to try.

I chose the pg_basebackup command just to not stop any database. It's out of circumstances to stop even the slave one... sorry...

I really don't know what else to do. Have tried everything! 

Lucas

On 10 January 2016 at 13:31, bricklen <bricklen@gmail.com> wrote:
Bottom-posting is the convention in the postgresql lists, and makes it easier to follow a long thread.

On Sat, Jan 9, 2016 at 3:16 PM, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:
My servers are not in the same network. A new pg_backup would take 30 hours to complete as I use --rate-limit 100MB.

If you had enough bandwidth, you could do some shell magic to parallelize the rsync commands, or use something like http://moo.nac.uci.edu/~hjm/parsync/ to do that. If you are limited by bandwidth, then a single rsync run is probably what you're stuck with.
 
I really need to put his server up! =\

If you were running zfs you could also take a snapshot of the fs and use that for your base backup, but I assume you would have mentioned that if it was an option.

 
I don't think that running a pg_basebackup one more time will solve the problem, because I've already done that!
I could run actually, but the problem is that it takes 30h! hahahahah

What is the --pgdata=- in your original command? Are you perhaps in the wrong directory and not getting all the required files?
 

I'm out of fresh ideas. The rsync command is what I would go with, given that I can't think of any other commands to try.

 

Have a look:

Note that there are some limitations in an online backup from the standby:
 
The backup history file is not created in the database cluster backed up.
There is no guarantee that all WAL files required for the backup are archived at the end of backup. If you are planning to use the backup for an archive recovery and want to ensure that all required files are available at that moment, you need to include them into the backup by using -x option.

You had that in your original command I believe.


В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump problem with dropped NOT NULL on child table
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Synchronous replication