Re: [PG-Advocacy] Is Oracle using Gitlab Failure against PostgreSQL?

On Fri, Feb 10, 2017 at 4:03 PM Gunnar "Nick" Bluth <
gunnar(dot)bluth(dot)extern(at)elster(dot)de> wrote:

> Am 02/10/2017 um 08:13 AM schrieb Sameer Kumar:
> > Hi,
> >
> > I came across this post in LinkedIn. I am not easily annoyed but somehow
> > this one has got my attention and not in a positive sense-
> >
> > https://www.linkedin.com/groups/77941/77941-6233195170771410945
>
> That's a closed group AFAICS, and I'm not really feeling like dipping
> into it just to get annoyed ;-/
> Can you sum up what's going on in there?
>

This is what the post said-

"
Any thoughts on the Gitlab database incident? Seems like they were using
the Free PostgreSQL database and some sort of replication that didnt work,
and they were not able to restore the database from the replicated versions.

The question is, would this have happened if the Oracle database, Oracle
Data Guard, Enterprise Manager monitoring of the Data Guard process, RMAN
incremental backups of the datanbase, and RMAN backups of archive logs had
been used? Interesting thought.
"

I just could not take it and felt an urge to reply -

"... It is bad configuration and bad practices (or rather lack of it)!
....... Remember that database is database - Oracle or PostgreSQL. It needs
reliable infra and storage to ensure its own reliability. Now unless Oracle
as a database can take SAN backup or take a RMAN backup while one was never
configured, I don't think running Oracle would have made any difference
"

To my surprise and annoyance the poster replied back-
"... The point is Oracle has better DBA utilities, such as Data Guard and
RMAN, out of the box when you install the Oracle binaries. PostgreSQL has
no such utilities like Data Guard, so Gitlab relied on scripts and the
command line ...... A PostgreSQL expert has pointed out that a third party
tool Repmgr, which seems to work in the same way as the Oracle Data Guard
Broker to reinitiate the standby at a higher level, could have avoided this
issue.
"

>
> > Question is, is there anything Postgres can really learn from this
> failure?
>
> Maybe re-order the docs? From what they made public, it seemed they
> either started backing up with a 7.x or early 8.x release and never
> adjusted the procedure to the new possibilities (LVM snapshots?!?
> Really?!?) or they stopped reading too early... :/
>
> Regards,
> --
> Gunnar "Nick" Bluth
> DBA ELSTER
>
> Tel: +49 911/991-4665 <+49%20911%209914665>
> Mobil: +49 172/8853339 <+49%20172%208853339>
>
> --

--

Best Regards,

*Sameer Kumar | DB Solution Architect*

*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069533

T: +65 6438 3504 | www.ashnik.com

Skype: sameer.ashnik | T: +65 8110 0350

[image: www.ashnik.com] <http://www.ashnik.com/>
<https://www.ashnik.com/resources/events/big-data-talk-transformation-series-your-search-for-analytics-brings-you-here/>