Greetings,
* Haroldo Kerry (hke...@callix.com.br) wrote:
> The bottleneck at dump is CPU (a single one, on a 44 thread server), as we
> are using the -Fc option, that does not allow multiple jobs.
> We tried some time ago to use the --jobs option of pg_dump but it was
> slower, even with more
Jeff,
We are using the following command to dump the database:
docker exec pg-1 bash -c 'pg_dump -v -U postgres -Fc
--file=/var/lib/postgresql/backup/sc2-ssd.bkp smartcenter2_prod' 2>>
/var/log/sc2-bkp-ssd.log &
The bottleneck at dump is CPU (a single one, on a 44 thread server), as we
are
On 5/30/19 5:08 PM, Haroldo Kerry wrote:
> Hello,
>
> We are migrating our PostgreSQL 9.6.10 database (with streaming
> replication active) to a faster disk array.
> We are using this opportunity to enable checksums,
I would stay away from performing 2 big changes in one go.
regards,
fabio
> 2019年5月31日(金) 6:53 Haroldo Kerry :
>>> On Thu, May 30, 2019 at 12:54 PM Steven Winfield
>>> wrote:
>>
>> >Has anyone been through this type of problem?
>> >
>>
>> You could set up a new, empty db (with checksums enabled, etc.) on the
>> new hardware and then use logical
On Thu, May 30, 2019 at 11:08 AM Haroldo Kerry wrote:
> Hello,
>
> We are migrating our PostgreSQL 9.6.10 database (with streaming
> replication active) to a faster disk array.
> We are using this opportunity to enable checksums, so we will have to do a
> full backup-restore.
> The database size
>Has anyone been through this type of problem?
>
You could set up a new, empty db (with checksums enabled, etc.) on the new
hardware and then use logical replication to sync across all the data from the
existing cluster.
(This logical replica could be doing binary replication to hot standbys
On Thu, May 30, 2019 at 12:08:04PM -0300, Haroldo Kerry wrote:
Hello,
We are migrating our PostgreSQL 9.6.10 database (with streaming replication
active) to a faster disk array.
We are using this opportunity to enable checksums, so we will have to do a
full backup-restore.
The database size is
