Archive

Archive for the ‘databases’ Category

Operation Facebook, Anonymous To Destroy Facebook On 5th November


 

The hacktivist group Anonymous has issued a YouTube video in English, Spanish and German announcing plans to destroy the world’s biggest social network, Facebook.


The hackers offer anyone concerned with the spread of personal information on the web to join the cause and “kill Facebook for the sake of your own privacy” in the action that “will go down in history,” setting the date for November 5, 2011.

 

“Facebook has been selling information to government agencies and giving clandestine access to information security firms so that they can spy on people from around the world,” the video statement, recorded in a typical digitally-altered voice says.

Thanks from   & onTraz 

.

 

 

 

Advertisements

Facebook down for 2.5hours – “Worst Outage in Over Four Years”


Facebook Down 7.30pm GMT 23/09/2010 for 2.5hours

Facebook Down 7.30pm GMT 23/09/2010 for 2.5hours

Facebook Software Engineering Director Robert Johnson was kind enough to explain to a curious public exactly why Facebook went down earlier today, calling the mishap “the worst outage we’ve had in over four years.”

In a brief blog post, Johnson discussed last nights downtime, which began around 7.30pm. The site wasn’t functioning again for most users until around 10pm gmt.

the blog read…

Early today Facebook was down or unreachable for many of you for approximately 2.5 hours. This is the worst outage we’ve had in over four years, and we wanted to first of all apologize for it. We also wanted to provide much more technical detail on what happened and share one big lesson learned.

The key flaw that caused this outage to be so severe was an unfortunate handling of an error condition. An automated system for verifying configuration values ended up causing much more damage than it fixed.

The intent of the automated system is to check for configuration values that are invalid in the cache and replace them with updated values from the persistent store. This works well for a transient problem with the cache, but it doesn’t work when the persistent store is invalid.

Today we made a change to the persistent copy of a configuration value that was interpreted as invalid. This meant that every single client saw the invalid value and attempted to fix it. Because the fix involves making a query to a cluster of databases, that cluster was quickly overwhelmed by hundreds of thousands of queries a second.

To make matters worse, every time a client got an error attempting to query one of the databases it interpreted it as an invalid value, and deleted the corresponding cache key. This meant that even after the original problem had been fixed, the stream of queries continued. As long as the databases failed to service some of the requests, they were causing even more requests to themselves. We had entered a feedback loop that didn’t allow the databases to recover.

The way to stop the feedback cycle was quite painful – we had to stop all traffic to this database cluster, which meant turning off the site. Once the databases had recovered and the root cause had been fixed, we slowly allowed more people back onto the site.

This got the site back up and running today, and for now we’ve turned off the system that attempts to correct configuration values. We’re exploring new designs for this configuration system following design patterns of other systems at Facebook that deal more gracefully with feedback loops and transient spikes.

We apologize again for the site outage, and we want you to know that we take the performance and reliability of Facebook very seriously.

twitter facebook