Cause of today's Github outage

https://github.com/blog/744-today-s-outage

by jlangenauer • 16 years ago

214 115 16 years ago

github.com

geophile• 16 years ago

Anyone know what database system they use?

blutonium2• 16 years ago

MySQL. Not that using anything else would have prevented this or would help restore the table faster...

jbellis• 16 years ago

fwiw, Cassandra automatically takes a snapshot (which is basically instantaneous -- see http://www.riptano.com/blog/whats-new-cassandra-066 for a brief explanation why) before truncating or dropping a column family, exactly because it makes recovering from a foot/gun incident like this so much less painful.

devmonk2• 16 years ago

Rails makes this way too easy to do by accident.

ethangunderson• 16 years ago

No system could prevent it, but there are databases(Oracle and MongoDB off the top of my head, and I'm sure there are others) that implement slave delays specifically to help mitigate human error like this.

trezor• 16 years ago

Incorrect. The article states that they lost data between backup time and whenever the incident happened.

Any reasonable quality transactional database system has a transaction log for a reason. If you were using commercial DB system like Microsoft SQL Server or Oracle (even a decade ago), this would not be an issue. No data loss. Businesses should care about their data, and I guess this is why the commercial databases are still doing fine in a landscape increasingly dominated by FOSS everywhere.

I realize licensing costs do matter, but I can't fathom why people put up with the sad excuse of a RDBMS which is MySQL. For any nontrivial tasks it is slow, it's unreliable, attempting to secure your data by taking database backups (which seemingly can't even provide you with transactional safety!!!) renders the DB unusable and locked while backup is performed, having databases bigger than what you can store in memory makes it perform like a flat-file, etc etc ad infitum.

Surely there must be something better people can use which is still free? Postgres for instance?

chesser12• 16 years ago

> MySQL. Not that using anything else would have prevented this or would help restore the table faster...

The slowness of the restore sounds like they have to insert a text dump back into the database, rather than simply copy over the binary files. Even copying over 1 TB from a single hard drive or between EC2 instances would only take a few hours, not days.

And they weren't using binlogs.

And they didn't separate out their test from production environment, which is understandable when you're in demo mode but not after a couple years and half a million users.

burgerbrain3• 16 years ago

Good thing git is distributed. I've been working on my code all day and never even noticed!

axod• 16 years ago

So what's the point of using github if you don't notice it's offline?

burgerbrain3• 16 years ago

Github provides a convenient place for me to publish my work to the world, allowing others to pull it as they desire (my work machine is a laptop, and can never be relied upon to be up, or at any particular address). Because git is distributed my workflow is not effected in the slightest by "somebody else's" (github's) completely separate repo being down.

Contrast this with something older like subversion and sourceforge. If sourceforge went down you were shit out of luck.

seanmcq• 16 years ago

Lesson, don't let your CI machine talk to your production servers (firewalls are good at this).

nettdata2• 16 years ago

In my environment, our Dev's (individuals or environments/subnets) don't have access to PROD or QA, and our CIT boxes are in DEV. Likewise, QA and PROD only have access to their own environments.

We have a build master that promotes a reviewed deployment package to QA and/or PROD environments, where the appropriate QA or PROD operations folks do the actual deployment.

It's a luxury to have the resources available for this, but it's a life saver, because it really is stupidly easy to make a simple mistake and totally screw things up.

The last time something similar happened to me, it happened to be at the end of a REALLY long day. And what do you know... that day was then made 24 hours longer, interspersed with the occasional cat nap while backups were being restored and verified.

Fun times. Not.

smokinn• 16 years ago

I'm not so sure it's a luxury. Maybe it is if your startup is servicing a group of techies who have knowledge of what problems lay in the background but most clients don't know and don't care.

It's not that hard to keep up really. It's a question of a day or two of setup and then the hardish part of constant discipline to not take the "easy way out" and poke holes into the segregation you've set up. Mainly it takes a single team lead or CTO or whatever to be really explicit that you just don't break the steps and you'll avoid a LOT of problems. You'll still have problems, problems are inevitable, but in general you'll have mitigated them and with a proper backup and merge procedure you'll minimize downtime.

jrockway4• 16 years ago

Interesting idea. I wonder if it would be worthwhile to store server information in LDAP, add a field for environment type, and then teach your server components to act on that information. Then when the dev app server connects to the prod database, the database checks the server name, sees that it's dev, and refuses the connection.

michael_dorfman2• 16 years ago

Nice, but still too specific.

Lesson: don't let anything talk to your production servers.

Make it as difficult as possible for anyone to log in. Treat production as if it were a loaded gun. You shouldn't be touching it unless you absolutely have to, and even then, you need to be vigilantly aware of the consequences of your actions.

arethuza2• 16 years ago

Maybe I should go and put in a reference to this thread in yesterday's thread about how you don't really need firewalls...

jlangenauer2• 16 years ago

I think it's a measure of the goodwill in the community for Github (and perhaps, the fact that a lot of us have done something similar in the past) that they won't cop much flak at all for this.

binaryfinery2• 16 years ago

I don't know. I use github, but my paid, private repos are elsewhere. The fact that someone, anyone, can run against the production system and nuke it raises some basic questions about password storage. I don't run a site anything like github, but my production and test databases have different passwords and none of them are stored in a way that the test environment could get access to the live db, nor could the tests be run on the production environment. There's bad luck and theres asking for trouble.

alextgordon2• 16 years ago

If github spent their time so that their site raised absolutely no basic questions, then they'd still be in beta by now.

jrockway4• 16 years ago

So basically, you don't make mistakes, only other people do. Is it cold up there on that high horse?

risotto6• 16 years ago

I wonder if this is a rails thing. It's an out of the box pattern to put production, development and testing credentials into one database configuration file.

Also from what I know Github is a flat org where all the devs have ability to do work in production. My company is like this too, and while it sometimes leads to scary mistakes, it also leads to massive productivity over having to go through a release engineering team.

woan• 16 years ago

rookie mistake, better security if they isolate their networks too...

gregwebs2• 16 years ago

I don't know why you first got down-voted. I have never worked on a project where a testing environment could access the production db.

sigzero• 16 years ago

Yeah that is just insane. We typically run prod, stage, test, dev. The test and dev instances are even in another dmz.

storborg• 16 years ago

I think he got downvoted for calling the GitHub team "rookies". Sure, they may not have tons of experience running 5-nines systems, but they've clearly built a great product that a lot of people love and respect.

aaronbrethorst• 16 years ago

Ouch. I think we've all done this once or twice, in some fashion or another. I'm just happy they're so open about it. Learning experience == good thing.

From Chris' Twitter stream (http://twitter.com/#!/defunkt):

Seriously, I blame whoever wrote our crappy continuous integration software.

Oh that's me

nigelsampson• 16 years ago

Exactly, I don't think you've really lived till you've experienced that pit of your stomach feeling when you realise you've just wiped out a product website / database.

Thankfully for me it was a small website and no one really noticed. I can't imagine what that feeling would be like on something like github.

wccrawford• 16 years ago

I did it for the main test database, and STILL felt like crap. SO many headaches.

mathgladiator• 16 years ago

I once messed up a table that was responsible for a custom-distributed auto-increment field. If you roll that back and don't reset some servers, you have new data overwriting old data. Very bad stuff.

SkyMarshal2• 16 years ago

> Exactly, I don't think you've really lived till you've experienced that pit of your stomach feeling when you realise you've just wiped out a product website / database.

Or sent a test email to thousands of customers in your prod database encouraging them to use web check-in for their non-existent flight tomorrow.

Yeah, did that five years ago, talk about heart-attack-inducing. Quickly remedied by sending a second email to the same test set, thankfully, but that's the kind of mistake you never forget.

1337p3376• 16 years ago

I suspect that this is why people tend to understand when GitHub goes down, and this allows them to be more open. All (or nearly all) of GitHub's users are tech-savvy, so we tend to understand the problems.

seldo2• 16 years ago

My worst was discovering I had written a unique ID generator which was (due to me typing "==" instead of "!="), producing duplicate IDs -- and not only that, it was producing them at exponentially increasing rates -- and every duplicate ID was destroying an association in our database, making it unclear what records belonged to who.

It was not a good day.

Jabbles• 16 years ago

Like when the google engineer added "/" to the list of bad URLs, thereby marking every single website (!) as possibly dangerous.

http://googleblog.blogspot.com/2009/01/this-site-may-harm-yo...

Now that would be a bad feeling.

blutonium2• 16 years ago

Context: https://github.com/defunkt/cijoe

xentronium• 16 years ago

I didn't even notice, maybe because it was Sunday and none of my data seems to have been lost. Well, except for the wiped events but I can live with that.

chunkbot• 16 years ago

I thought systems written in Erlang never go down! ;-)

tlb• 16 years ago

Forthright and classy. Compare to register.com, which had a big DNS outage Friday (affecting anybots.com) and never admitted to a problem.

invisible• 16 years ago

I believe they had a message on their homepage during the event about being DDoSed, but yeah no after-remarks is kind of ugly in my opinion. They could at least post and hide it from the general customer.

1) http://seclists.org/nanog/2010/Nov/415

bytesong2• 16 years ago

Minutes before the outage, my account would seem non-existent and all my repositories gone. They really scared the hell out of me.

This will be a good reminder for me to always keep a local copy.

SkyMarshal2• 16 years ago

Since it's git-based, is it even possible to not keep a local copy? I thought everything that goes into github has to be committed to your local git repo first?

bytesong2• 16 years ago

Well, there is always a local copy since you have to commit to the local repo first before you push it to github. That is, of course, as long as you don't remove it for no apparent reason.

damncabbage• 16 years ago

I was walking through someone's capistrano scripts, and suddenly everything came back "Not Found". My first thought was that the guy had just starting cleaning up his account. :)

latch• 16 years ago

I agree with what's been said so far. 1 - Shit happens 2 - We've all done stupid stuff 3 - Testing environment shouldn't have access to production

What hasn't been said is how refreshing it is to see an honest and quick explanation. I know this type of approach is getting more and more common (see the foursquare outage), but in the grand scale of things, its still quite rare.

chesser12• 16 years ago

I have a slightly higher threshold for considering something refreshing.

It took several levels of basic mistakes for this to happen AND for the restore to be as slow as it is.

Using MySQL with no transactions, no binary backups, no way to do a quick restore, and no separation of dev/production. DROP as opposed to DELETE cannot be rolled back and is therefore scary -- unless you aren't using transactions in the first place, in which case, WHEE!

matwood• 16 years ago

I don't have much MySQL experience, but have lots of experience with other RDBMSs. Large restores take a long time no matter what. They shouldn't take days, but since we don't know how large the events table was we have no way of knowing if a faster restore was possible. A hot restore which it sounds like what they are doing may take longer by simple fact that it's restoring while the table is in use.

And DROPs (or truncates) are almost always used if the goal is to remove all the data in a table like you would want if rebuilding the entire system. Something like 100M record transaction is not generally considered a good thing.

1337p3376• 16 years ago

It kind of makes me wish NILFS2 would become production-ready faster. Give MySQL its own partition, and just roll back to a previous checkpoint if you wipe everything. Not a substitute for backups, but a pretty speedy way to recover for a minor snafu like this.

jacques_chester2• 16 years ago

NILFS is very nifty for write-oriented work, but I'm not sure if that's their workload.

But if you're logging stuff, NILFS rocks: http://lists.luaforge.net/pipermail/kepler-project/2009-June...

ammmir3• 16 years ago

simply checking if you're talking to a production instance could avert something like this. having some metadata in the db about whether the data stored there is acting as production and at what version and deployment level, so tests can have a sanity check before destructive activities.

ammmir3• 16 years ago

why the downvote?

seldo2• 16 years ago

Presumably because the comment is obvious, unhelpful, and somewhat mean-spirited. I don't think anybody here needs a lesson in how to avoid accidentally dropping your production database.

jacques_chester2• 16 years ago

Well done on coming clean. However this is why the dinosaur pens have such arduous red tape -- to try and catch serious errors before they hit production. A mate of mine works in that world and he regularly stops code going into production that would hose mission-critical government data.

I prefer my agility to remain on the dev-and-test side of the fence.

dacort• 16 years ago

Second time I've heard of this happening fairly recently. Another incident, same cause. http://www.bigdoor.com/blog/bigdoor-api-service-has-been-res...

spudlyo• 16 years ago

This was pretty painful. Their backups were too old, so it was necessary to do InnoDB data recovery rather than a straight-forward restore from backup.

Since InnoDB table spaces never shrink, 80G of their truncated data was still all available in a single monolithic ibdata file. An InnoDB recovery tool named page_parser read their 80G ibdata file and spits out a maze of 16k InnoDB page files organized by an arbitrary index id.

There are two internal InnoDB meta tables called SYS_INDEXES and SYS_TABLES which can give you a mapping from table name to PK index id. Unfortunately after the mass TRUNCATE all the tables got new index mappings, so it became a bit of table hide-and-seek.

The InnoDB recovery tools lack a certain polish and maturity. You need to create a C header file for each table you want recover from the pile of 16k page files. You end up having to build a separate version of the constraints_parser binary for each table. There were bugs with the output of negative numbers, unicode handling, VARCHAR types with >= 127 characters, and some edge cases where InnoDB chooses to store CHAR(15) types as VARCHARs internally. Aleksander at Percona really saved the day, he was able to find and fix these bugs pretty quickly.

I remember that magic moment when I finally was able to successfully checksum a huge block of the recovered data against the too-old-to-be-useful backup.

"I love the smell of CRC32 in the morning. It smells like... victory."

peterwwillis3• 16 years ago

If someone ever produces a good book of best practices for sysadm/syseng, please provide examples like these of why it's important to follow these best practices.

Yes, we've all made silly mistakes. But if you're in that design meeting and somebody asks, should we do ABC in case of XYZ, try not to think about how complicated or time consuming it might be to do ABC. Think about the worst case. If not doing it could at some point bring down the whole business, perhaps you should ponder it some more.

Actually, screw a book... Does anyone else want to start some wiki pages their experiences with screw-ups, the causes and the solutions? Does this exist in a comprehensive way and I just haven't found it?

ojilles• 16 years ago

Given the topic, it would be good to make mirrors of these pages before doing anything else with them.

michael_dorfman2• 16 years ago

While a book of screw-ups might be amusing, I think it might be more instructive to look at the "old school" ways that screw-ups like this were avoided.

I worked, back in the dark ages, for a health insurer that had two parallel environments-- one for testing/development, and one for production. None of the developers were allowed anywhere near the production environment. There was one full time employee, a former developer, whose primary job was to move code into production-- which he would only do when he received a signed document authorizing the change. Said document included the telephone numbers where the developer responsible for the code would be for the next 24 hours, so that one of the operators could call you in the middle of the night if your code caused any problems to the system.

At the time, I used to think that this was ridiculous. After managing a staff of programmers myself, I'm not so sure.

viraptor• 16 years ago

It depends on the software a bit, but I got a taste of "programmers not allowed on production" environment (in a very small scale). The problem I run into is that you have no idea what's going on on the production environment. Some characteristics are maybe reproducible on the dev site, but actual users will always do something differently. Sometimes not being able to poke the live system in a specific way while it's live, will cost you weeks of guessing in the dev environment.

Then again, there is no perfect solution for this, is there? If you tried installing new version with more debugging points, you'd be deploying something unstable over something previously unstable and trying to push more data out which might be problematic in itself. I'm not even going into "rollback to stable didn't work" scenarios :(

grandpa• 16 years ago

97 Things Every Software Architect Should Know is a pretty good starting point.

http://97things.oreilly.com/wiki/index.php/97_Things_Every_S...

peterwwillis3• 16 years ago

Thanks, i'll give this a read.

Fluxx• 16 years ago

We have a great sysadmin at work, and I've learned 3 very important lessons:

Have redundant everything. Backup everything. Provide tools to talk to production systems, databases, but make them read only and make it hard to mess with production systems unless you're reallllllly sure you know what you're doing.

jrockway4• 16 years ago

I try to make my apps work against SQLite and the production database, so I can run all my tests against an in-memory SQLite database. This makes the tests run Really Fast, and it prevents a configuration error from causing my production data to go away.

(It's not possible to do this in every case, especially if you make heavy use of stored procedures and triggers, but I don't. If I need client-independent behavior or integrity checks on top of the database, I just use a small RPC server. This makes testing and scaling easier, since there are just simple components that speak over the network. Much easier than predicting everything that could possibly happen to the database.)

sankara• 16 years ago

May be it's foresight or may be it's just paranoid. We've always used a entirely different username/password in prod and the password for prod never sits in the config files. Kind of saved us a couple of times. Sometimes it doesn't require a highly sophisticated setup to prevent a catastrophe.

random42• 16 years ago

I am a software developer, so I know "shit happens", but having the same configuration for database as testing environment, (same superuser name and password), which is not isolated from test environment, is pretty criminal even for a first time mistakeIMHO, especially for a product like github whom business, small and big trust with there business critical piece ("repository").

If I were running some critical code, I would have seriously reconsider github, or at-least ask for a detailed explanation on their engineering practices and fail-safe mechanisms.

thibaut_barrere• 16 years ago

Can you share more details about how you usually work ?

scorpion032• 16 years ago

I think the fact that they have been able to recover all critical data soon and will even update the event table over the next few days clearly displays their competence.

Github isn't facebook and not seeing the last week's "activities" timeline for a few days isn't really that much of a problem.

chesser12• 16 years ago

> I think the fact that they have been able to recover all critical data soon and will even update the event table over the next few days clearly displays their competence.

Taking a few days to restore a table indicates they only had a text dump of it. The details of how they screwed up indicate they were new to the idea of data robustness, despite it being the core of their business.

Being a competent home user and being a competent data-robustness company involve slightly different levels of expertise.

1337p3376• 16 years ago

I can only hope it shocks some sense into kids that use GitHub for distribution rather than putting a tarball named $name-$version.tgz (or bz2 or xz or whatever). As much as I love GitHub, is has been the bane of my automated-build existence. I don't want to ever have to make a build script that guesses at a SHA1 (or punts by doing a clone at depth zero) again.

yosh• 16 years ago

git ls-remote will help you to get the hash of HEAD. It's much cheaper than doing a zero-depth clone.

_urga2• 16 years ago

I moved my repos off GitHub to my EC2 server a month or two back since they're private and I was only using GitHub for keeping a copy of my code offsite. It's faster for simple push/pull and considering the sunk cost of my EC2 server, also free. I was trying to browse some repos on GitHub yesterday during the downtime and was thankful that my own were still available.

_urga2• 16 years ago

Also, if you just need something for replicating code, Amazon is offering free micro servers on new accounts for up to a year I think.

mkramlich• 16 years ago

Kudos to them for having the guts to say publicly that they accidentally destroyed their production database.

It's been a great service, and I think as long as this kind of thing is rare, and none of my code repositories get corrupted or destroyed, I plan to stick with them.

donw• 16 years ago

This is why it's important to isolate production from other environments. Three rules have kept me from ever borking a production database:

1. Production DB credentials are only stored on the production appservers, and copied in at deploy time.

2. The production DB can only be accessed from the IPs of the production webfarm.

3. Staging, Testing, Development, and Everything Else live on separate networks and machines than production.

oddi• 16 years ago

While this is part of the problem, to me it seems like they didn't have proper restore procedures or at least hadn't tested them enough. There are countless ways to corrupt a database and restoring from backup is part of most remedies.

fizx• 16 years ago

Mysql 5.6+ has delayed replication. Until then, there's always tools like:

http://www.maatkit.org/doc/mk-slave-delay.html

Cause of today's Github outage

Related Stories