News for hackers. Stuff that matters.

A comment on Inside the longest Atlassian outage. Parent comment

Re:Inside the longest Atlassian outage by akie on Wednesday April 13, 2022 @01:23PM (#31017415)
Now every time you run a database migration, you have to adjust N tables - and in Atlassian's case, N is 200000. Is that better? It depends. There is no "best" way of doing multitenancy.
[ Parent | on HN ]
Re:Inside the longest Atlassian outage by hnlmorg on Wednesday April 13, 2022 @02:50PM (#31018623)
That’s just an automation issue. It’s not like you have to write a bespoke database migration script per DB.
[ Parent | on HN ]
Re:Inside the longest Atlassian outage by robertlagrant on Wednesday April 13, 2022 @04:24PM (#31019796)
The bug we are mitigating was also just an automation issue.
[ Parent | on HN ]
Re:Inside the longest Atlassian outage by hnlmorg on Wednesday April 13, 2022 @04:35PM (#31019898)
It’s also pretty easy to foobar up a single DB instance if you don’t have proper guardrails in place.

Automation wasn’t the issue here. It’s the symptom not the cause.

[ Parent | on HN ]
Re:Inside the longest Atlassian outage by robertlagrant on Wednesday April 13, 2022 @05:23PM (#31020476)
No, the symptom was the loss of customer data.
[ Parent | on HN ]
Re:Inside the longest Atlassian outage by doliveira on Wednesday April 13, 2022 @06:57PM (#31021344)
Way easier, actually.
[ Parent | on HN ]
Re:Inside the longest Atlassian outage by doliveira on Wednesday April 13, 2022 @06:56PM (#31021340)
There is a worst way of doing multitenancy, and that is sharing a single big table.
[ Parent | on HN ]