Live data from Hacker News

Gitlab Epic Issue Relationships Deleted

status.gitlab.com

11–20 of 30 posts

Re: Gitlab Epic Issue Relationships Deleted

#11
post #4

I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430

Huh. While trying to figure out the reasoning behind the name used, TIL that "epic" has acquired a new meaning of "(computing) In software development, a large or extended user story."

https://en.wiktionary.org/wiki/epic

Re: Gitlab Epic Issue Relationships Deleted

#12
post #4

I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430

I didn't realize this wasn't common knowledge. It's been part of my everyday life for over ten years and several jobs.

You can also add them to GitHub via ZenHub and other such tools.

Re: Gitlab Epic Issue Relationships Deleted

#13
post #7
post #3

Seems like they have it mostly resolved, the releationships were restored from a backup 3 hours prior to the incident, and they are working to restore the data for the 313 (sic.) items still affected: https://gitlab.com/gitlab-org/gitlab/-/issues/348547

I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent

Worst case in 2021 should be a daily full backup + transaction logs. That's enough to get you point in time recovery.

On AWS, EBS snapshots are incremental (I didn't know that until studying for AWS certification), so you could schedule a snapshot every 5 minutes if you wanted.

Looking at the timeline, I'm just gonna repeat something I said in another thread this week: it's easy to underestimate how long it takes to do basically anything with a few hundred GB of important data.

Re: Gitlab Epic Issue Relationships Deleted

#14
post #4

I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430

That's because github isn't trying to be a replacement for JIRA and source control for most teams.

https://github.com/features/issues

Scroll down to "break issues into actionable tasks", and they have an example that's even labeled as an "Epic". They are definitely headed in the same direction as Gitlab.

Re: Gitlab Epic Issue Relationships Deleted

#15
post #7

Earlier quoted context omitted.

I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent

Worst case in 2021 should be a daily full backup + transaction logs. That's enough to get you point in time recovery. On AWS, EBS snapshots are incremental (I didn't know that until studying for AWS certification), so you could schedule a snapshot every 5 minutes if you wanted. Looking at the timeline, I'm just gonna repeat something I said in another thread this week: it's easy to underestimate how long it takes to…

Found this out recently when my 250GB database had to roll back a transaction and was stuck for hours :/

Restoring a new database from the AWS snapshot and transaction logs was literally faster.

Re: Gitlab Epic Issue Relationships Deleted

#16
post #4

I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430

Huh. While trying to figure out the reasoning behind the name used, TIL that "epic" has acquired a new meaning of "(computing) In software development, a large or extended user story." https://en.wiktionary.org/wiki/epic

[deleted]

Re: Gitlab Epic Issue Relationships Deleted

#17
post #7
post #3

Seems like they have it mostly resolved, the releationships were restored from a backup 3 hours prior to the incident, and they are working to restore the data for the 313 (sic.) items still affected: https://gitlab.com/gitlab-org/gitlab/-/issues/348547

I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent

For a full backup of a huge DB a three-hour window is pretty small, but I doubt that is what is happening here.

A far more common setup is regular full backups, often daily though sometimes more/less frequent, with much smaller transaction log backups at high frequency, perhaps every 15 minutes, between. That way you lose at most what has happened since the last log backup, and you can restore to any point in time between the full backup and the last log backup. It takes more effort to restore as you need to first restore the full then restore (replay) the log backups in sequence until the point you care about.

Sometimes there is a third layer between: differential backups. These are usually much smaller than a full backup, while also smaller (and less faf/time to restore) than the log backups for the period they cover, but don't offer point-in-time recovery.

Re: Gitlab Epic Issue Relationships Deleted

#18
post #4

I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430

Huh. While trying to figure out the reasoning behind the name used, TIL that "epic" has acquired a new meaning of "(computing) In software development, a large or extended user story." https://en.wiktionary.org/wiki/epic

The name is an extension of '[user] story' - in literature, an epic is a collection of related stories (as in, The Epic of Gilgamesh), so they decided to call a collection of User Stories an Epic.

Re: Gitlab Epic Issue Relationships Deleted

#19
post #7

Earlier quoted context omitted.

I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent

For a full backup of a huge DB a three-hour window is pretty small, but I doubt that is what is happening here. A far more common setup is regular full backups, often daily though sometimes more/less frequent, with much smaller transaction log backups at high frequency, perhaps every 15 minutes, between. That way you lose at most what has happened since the last log backup, and you can restore to any point in time be…

Out of curiosity, how do transaction logs handle things like created_at fields, or randomly generated UUID, which rely on contextual data? Is the server time/rng seed faked for each replayed transaction?

Re: Gitlab Epic Issue Relationships Deleted

#20
post #3

Seems like they have it mostly resolved, the releationships were restored from a backup 3 hours prior to the incident, and they are working to restore the data for the 313 (sic.) items still affected: https://gitlab.com/gitlab-org/gitlab/-/issues/348547

What is "(sic)" about "they are working to restore the data for the 313 items still affected"?
Post reply on HN