On 25/2/19 2:06 μ.μ., Boris Sagadin wrote:
I think it should. I set it to unlogged on target/slave server only. One other
table which is much smaller and already replicated receives changes from master.
Ah, ok then.
About settings copy_data to false, nice idea, I'll try that too and compare
I think it should. I set it to unlogged on target/slave server only. One
other table which is much smaller and already replicated receives changes
from master.
About settings copy_data to false, nice idea, I'll try that too and compare
speed.
On Mon, Feb 25, 2019 at 9:51 AM Achilleas Mantzios
On 25/2/19 9:59 π.μ., Boris Sagadin wrote:
Doing an initial replica.
postgres 119454 93.5 25.9 34613692 32649656 ? Rs 07:16 32:45 \_ postgres:
10/main: bgworker: logical replication worker for subscription 24783 sync 16500
I've cancelled the sync, set the tables to unlogged type and
Doing an initial replica.
postgres 119454 93.5 25.9 34613692 32649656 ? Rs 07:16 32:45 \_
postgres: 10/main: bgworker: logical replication worker for subscription
24783 sync 16500
I've cancelled the sync, set the tables to unlogged type and started it
again. I think it helped, still much
On 25/2/19 8:52 π.μ., Boris Sagadin wrote:
Doing an initial replica and trying to find a bottleneck, Ubuntu 16.04, NVMe disks, PgSQL v10.7, AWS. With binary replication, DB is replicated at good speed, around 500MB/s. Trying LR now for a big
table (about 1.4TB with 2 indexes) and the speed is
Doing an initial replica and trying to find a bottleneck, Ubuntu 16.04,
NVMe disks, PgSQL v10.7, AWS. With binary replication, DB is replicated at
good speed, around 500MB/s. Trying LR now for a big table (about 1.4TB with
2 indexes) and the speed is only about 2MB/s.
Checked disk util with
