Noobaa migrate from internal postgres DB to external postgres DB

[mhtgrwl5]

Situation —

1. Noobaa 5.13 was tightly coupled with the requirement of internal postgres DB. So, the current running noobaa is using postgres.
2. I am planning to move from Noobaa 5.13 to latest due to major CVEs. But since it supports external postgres. I am planning to move the DB to external.

Question —

1. What are the steps that needs to be followed for movement of noobaa from internal to external?
2. What happens if the external DB crashes [Disaster happens — Data loss kind of scenario]?

[nimrod-becker]

Hi,
Thanks for posting the question.

1. There is no upgrade path within the code, but since those are two PSQL, dbdump on one side and then dbrestore on the new PSQL should work
2. The idea behind providing support for external DB is if you want to manage it on your own, including creating replication between several DB instances for H/A. So the short answer would be that any crash or unavailability would not be taken care by NooBaa, but on the other side you can set any H/A to satisfy your needs

[mhtgrwl5]

@nimrod-becker
Hi, Thanks for the reply.

I understand about the HA. Since, I already have a postgres that is already managed. I was thinking if I can utilise it.
Can you assist me with answers of two more questions?

1. In case the postgres DB of Noobaa crashes. How does noobaa manages it? Is it managing in a way where it can bring the db back up in the same state with all the data in it? Or something else?
2. If I will still take decision on migration to my external DB. Do you know which DBs I need to take dump of from Noobaa's PG DB? And till we do this, do we need to take down noobaa temporarily [If yes, how?]?

[nimrod-becker]

1. If the external DB crashes, the DB needs to start up again. NooBaa doesn't control it and can't bring it back up. Once it is up, if the data is there everything will continue the same. If there was some kind of corruption, then it would affect NooBaa to the point of losing data or inability to serve at all (Depending on what kind of corruption it is). This is why I suggest that using external would be for adding more assurance, like replicas, in which case a single crash won't affect the ability to serve. A single crash in a replicas setup also has a very low likelihood of corruption in the DB.

2. nbcore should be the one to take. Regarding taking it down, you can scale down the endpoints to 0 to make sure no new S3 operations are being handled, and then take the dump, make the move and after everything is up and running scale the endpoints back

[mhtgrwl5]

Thanks. I will try this out.