Re: Fastest option to transfer db?

Поиск
Список
Период
Сортировка
От Tomas Pospisek
Тема Re: Fastest option to transfer db?
Дата
Msg-id c9bb59a6-5b56-8b15-236e-91f1e5ab5220@sourcepole.ch
обсуждение исходный текст
Ответ на Re: Fastest option to transfer db?  (Israel Brewster <ijbrewster@alaska.edu>)
Ответы Re: Fastest option to transfer db?  (Israel Brewster <ijbrewster@alaska.edu>)
Список pgsql-general
I'm potentiall facing the same problem and would be interested in the 
solution. Is there any particular howto you followed?

Also at some point I'd like to cut of the link between the two DBs 
promote the copy to be the master and delete the original DB. Have you 
figured out the correct step for the cut-over to happen?
*t

On 13.09.21 23:10, Israel Brewster wrote:
> Ok, I have logical replication up-and-running (I guess - seemed to 
> simple to be working. Shouldn’t it be complicated, requiring many steps 
> and configuration changes?), maxing out one CPU core on each machine 
> (more or less), and showing network throughput of around 15M. If DU 
> changes are to be believed, it’s transferring data at about 
> 0.8GB/minute, implying something like a 8 hour transfer time.
> 
> Of course, since it is replication, it has the benefit that any data 
> that comes in during that 8 hour window should also be replicated, after 
> which the two systems should remain in sync allowing for zero (or nearly 
> so) downtime cutover. Which is nice.
> 
> Any gotchas I need to be aware of during this initial transfer window, 
> such as WAL files building up on the source machine?
> 
> ---
> Israel Brewster
> Software Engineer
> Alaska Volcano Observatory
> Geophysical Institute - UAF
> 2156 Koyukuk Drive
> Fairbanks AK 99775-7320
> Work: 907-474-5172
> cell:  907-328-9145
> 
>> On Sep 13, 2021, at 10:10 AM, Michael Lewis <mlewis@entrata.com 
>> <mailto:mlewis@entrata.com>> wrote:
>>
>> What version of Postgres is the source? Can you make use of logical 
>> replication?
> 




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

Предыдущее
От: Raymond Brinzer
Дата:
Сообщение: Re: The tragedy of SQL
Следующее
От: Wim Bertels
Дата:
Сообщение: Re: The tragedy of SQL