Perhaps we will start to see posts about people abandoning Postgres and moving back to MongoDB, completing the circle?
Dribbble is Back With a Day of Data Lost
11–20 of 22 posts
Re: Dribbble is Back With a Day of Data Lost
#12Good disclosure on the part of Dribbble. I have some sympathy; I've seen a Linux server randomly corrupt its file cache, no idea why. Google's study found 8% of DIMMs experienced at least one memory error a year. If you can't trust your RAM, what can you trust? http://research.google.com/pubs/pub35162.html
In ECC we trust.
Re: Dribbble is Back With a Day of Data Lost
#13Not trying to be an ass here or anything but something doesn't add up. I understand the memory corruption idea but I wouldn't think that would replicate to the other postgresql server. So am I right in thinking there was no slave ever here?
I don't know exactly how the replication in postgres works, but I can think of scenarios where bit flipping in RAM gets propagated to the slave(s) (e.g., newly-generated data which currently resides only in RAM gets corrupted and then fsync'd to disk, at which point it gets replicated). The real question is, why on earth would they use non-ECC memory on their database server.
Perhaps because the database server is a cloud server from someone like Amazon, Mediatemple or Linode where you have no control on the underlying hardware.
Re: Dribbble is Back With a Day of Data Lost
#14Re: Dribbble is Back With a Day of Data Lost
#15Perhaps we will start to see posts about people abandoning Postgres and moving back to MongoDB, completing the circle?
Re: Dribbble is Back With a Day of Data Lost
#16There is a lot of arm chair sysadmining going on, but remember, the team that built Dribbble is essentially 4 total people, 2.5 engineers, working with no outside funding. The fact that they've built the designer's equivalent of Github and keep it running as smoothly as it does is amazing. It's fine to provide suggestions, but this is a minor blip in an otherwise impeccable record of performance.
Re: Dribbble is Back With a Day of Data Lost
#17Re: Dribbble is Back With a Day of Data Lost
#18Earlier quoted context omitted.
In ECC we trust.
One of the great ironies of modern computing is that we stopped building ECC into consumer hardware right when we got enough RAM to really need it. What fraction of server hosting has ECC RAM? No one seems to know if Amazon EC2 does, for instance, which suggests it probably doesn't.
Re: Dribbble is Back With a Day of Data Lost
#19There is a lot of arm chair sysadmining going on, but remember, the team that built Dribbble is essentially 4 total people, 2.5 engineers, working with no outside funding. The fact that they've built the designer's equivalent of Github and keep it running as smoothly as it does is amazing. It's fine to provide suggestions, but this is a minor blip in an otherwise impeccable record of performance.
If there's one social norm I'd love for HN, it would be "If you build things, we're on your side." (I hope that the normative intent of this is clear enough to not require 2 paragraphs of inoculations against nitpickery. On second thought, if there were two social norms I'd like for HN, that plus "Default to not nitpicking.")
Re: Dribbble is Back With a Day of Data Lost
#20Perhaps we will start to see posts about people abandoning Postgres and moving back to MongoDB, completing the circle?
the point is, no software can prevent hardware failure , not even mongodb ;)