Thread: [pgsql-advocacy] [PG-Advocacy] Is Oracle using Gitlab Failure against PostgreSQL?
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-
Question is, is there anything Postgres can really learn from this failure?
Regards
Sameer
--
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
Attachment
On Fri, Feb 10, 2017 at 4:03 PM Gunnar "Nick" Bluth <gunnar.bluth.extern@elster.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.
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
Mobil: +49 172/8853339
--
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
On Fri, Feb 10, 2017 at 7:25 PM Wei Shan <weishan.ang@gmail.com> wrote:
Funny enough, the admin of the group, who was the thread starter, closed the thread after his final response.
I know. I guess my final comment made him see some light (and realize that it's not working)-
"
..... Secondly, you have missed the point completely (despite it being pointed out by so many on this post) - The failure was not because of the database but the underlying infra and redundancy of provided by infra. Having said that, I can see the purpose of this post is more to have a negative marketing and less to have an open debate....
"
He just wanted to make a final comment (and a conclusive one). Clearly depicts how open he or the group is towards comments/suggestions!
That is one thing I respect about community. Uber wrote a blog on why they moved on from Postgres and we had community leader jumping in at the opportunity to make Postgres better. In other user groups people can not even take straight facts!
On 10 February 2017 at 11:22, Martín Marqués <martin@2ndquadrant.com> wrote:El 10/02/17 a las 05:01, Gunnar "Nick" Bluth escribió:
>
>> 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... :/
Simon Riggs wrote a nice blog after the incident, which IMO details the
flaws in the incident, with the conclusion that postgres wasn't in fault
there.
http://blog.2ndquadrant.com/dataloss-at-gitlab/
I don't think the issue they had has anything to do with how the
documentation is organized. This was just bad system administration
policies (you can see a bunch of changes they did after the incident
which aim at preventing from happening again).
In particular, the same problem would have happened with any database
engine, including Oracle. (I'm taking about the administrator deleting
all the data files)
Regards,
--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy--Regards,
Ang Wei Shan
--
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