From: | Siraj G <tosiraj(dot)g(at)gmail(dot)com> |
---|---|
To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Approach for DB migration |
Date: | 2025-08-07 04:21:18 |
Message-ID: | CAC5iy62RcAeMi63PDVuCv6AWQKYkCO=91M-gTScqbPvFNwALGw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yes Ron, database migration service. But it works better if we have to
migrate all the DBs in one shot since it converts the target DB into a read
replica during the migration.
Regards
Siraj
On Thu, Aug 7, 2025 at 9:33 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:
> On Wed, Aug 6, 2025 at 9:30 PM Siraj G <tosiraj(dot)g(at)gmail(dot)com> wrote:
>
>> Hello Experts!
>>
>> I have this environment with 100+ DBs and would like to migrate to GCP's
>> cloud SQL for Postgres.
>>
>> Primary: 48 CPUs, 48GB memory
>> Secondary/Read Replica: 80 CPUs, 128GB memory
>> PG version: 12.22 (we have already started the upgrade process)
>> OS: Ubuntu
>>
>> I would like to migrate 2 DBs first and a few more later. I was thinking
>> of logical replication, but wanted to take recommendations if there are
>> better approaches available. We cannot afford breaking the read replica due
>> to our read intensive app connects to this node.
>>
>
> GCP haa a migration service. Have you investigated it?
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Johnson | 2025-08-07 05:22:01 | Re: Approach for DB migration |
Previous Message | Ron Johnson | 2025-08-07 04:03:10 | Re: Approach for DB migration |