Actually, the death of Slashdot is a blessing in disguise. You see, Slashdot is entirely responsible for the current global economic crises. When a nerd or other smart person first reads this site, he or she is instantly hooked on the discourse with other nerds, even if it's just inane drivel. As more and more nerds get addicted to Slashdot, productive grinds to a halt, causing companies to fail. The happened first in North America with the dotcom crash. As ubiquitous internet access spread around the world, so did Slashdot's productivity sucking force. That is why we're now in a global recession, except for Africa where there's been an on going recession ever since an unfortunately soul laid out a stone and a stick in a/. pattern thousands of years ago. Cowboy Neal is nobody more than a drug runner for the Bilderberger Group who plan to control all the intelligence in the world with their Slashdot drug.
Like in TNG espisode #34 where an organism eats the hulls of the USS Enterprise and the IKS Pagh? Who knew they were still using windows in the 24th century!
The price of ignorance, whether of technical or financial matters, has never been higher in our society and it is growing larger all of the time. My advice to these people would be to turn off American Idle and crack a few books or Google some basic knowledge instead of whining when the smarter and more educated people take all of their money.
Things are going to change very quickly once the depression is in full force. Those who have no knowledge will have no food. They won't have idle entertainment when all their money is going to buying the basics of life. They'll start putting a lot more energy into being productive.
You can get slightly better Isp than that, actually. For example, I get 4664 m/s vacuum Isp
DUDE!!! You must have a ton of warez!! Where can I sign up for Vacuum Isp?? My ISP suck0rs!! Im lucky if I get 3 Mb/s, but ur getting 4664!! NO FAIR!!!!1!
Yes, it would cause a high load on the replicant server, too. But it's okay if the replicant falls behind a little bit. Once the heavy demands of the backup are complete, the replicant can catch back up. Obviously, if both machines are loaded to near capacity, this won't work -- but by then you'd already be experiencing intermittant slowdowns (increased latency) at busy times of day.
The main delay is caused by disk bandwidth regardless of the backup method. It simply bogs things down when you read gigs of data off the disk.
And as an added bonus, if you configure the two machines to replicate both ways, you can switch between which one is the primary at any time. This allows you to take either machine offline to upgrade software or hardware or move the machine, etc. Some highend database software may have this functionality already. And there's the MySQL Multi-Master Replication Manager at http://code.google.com/p/mysql-master-master/ for MySQL. I'm not personally aware of anything for Postgres, but it may exist (and I imagine MMM could be easily re-written for it).
I think we're saying the same thing, just in different words. There are two things to backup: physical and temporal. First is the ability to keep everything working. That requires backup hardware and a working copy of the data. Second is the ability to access the data as it existed at a previous point in time. That requires a stable, detached copy of the data, usually stored on separate media for space and reliablity concerns.
I agree that not having a detached, stable copy of the *data* is not having a backup of the *data*. So having a second machine is definitely not a backup of the *data*. A second machine is a backup of *hardware* only. But having a backup of just the *data* is also not a *complete* backup. We've all heard stories of old media that can't be accessed because the hardware doesn't work or can't be found. A *data* backup is useless if you can't access it.
So a backup of hardware or a backup of data is indeed a backup, by definition. But neither is a *complete* backup solution, which includes both physical and temporal backups. Journalspace.com had some of the former and none of the latter.
And as long as the database can do that in a reasonable amount of time without affecting the performance of on-going database activity, that's great. But setting up a system capable of that is more complex than doing a straight file-system copy, hence "a bit tricky" in comparison, though not necessarily difficult.
And watch all your busy tables write-block and your site go unresponsive while pg_dump does its thing?
And wait for hours and hours while pg_restore executes millions of insert queries and rebuilds indices?
Sure, pg_dump (or whatever another database might use) works for tiny databases where a few seconds of latency is tolerable once a day. It's not tolerable when you're down for hours.
Keeping the database responsive when backing up a live database is what makes it tricky.
That's exactly what I'm talking about (though I didn't know the Windows parlance). The reasons for adding the slave machine are two: first, to have a hot spare should the first one go down, which is handy for doing software updates and other maintenance; and two, to avoid degraded performance during the backup. The second isn't an issue on a lightly loaded server, but on a busy box, it's a choice between keeping the box quick or having a quick backup.
Yep. The only trick is making sure your backup process completes before the log has over-written itself at the point when the backup started, and that the log is copied last. If you were backing up say 100 GB at 50 MB/s, it's going to take 34 minutes -- meaning the log better hold at least 34 minutes of updates, and many times that for a comfortable margin.
It's much simpler to create a snapshot and copy from that.
Semantics. It's a backup on the hardware level, but not the software level. It's like having two pumps at a well. Either can do the job so one is a backup, but someone can still poison the water.
What? Snapshots take at most a second. They're done on the filesystem layer, and updates are written to different blocks. Once you've finished copying the data off the snapshot, delete the snapshot and the old blocks are freed for use again. Databases often have the handy write pattern where most updates are done to the same or contiguous areas, so you usually have many hours/days before the filesystem is forced to overwrite the blocks in the snapshot if you don't delete it in time.
Any database worth its salt will keep everything synchronised to disk at all times. A query won't return unless the changes are written. The only issue can be if the OS or disk itself has buffered the writes, but transactional databases ensure consistency with an update log on disk (updates are first written to the log and another process commits those updates from the log to the database files).
And yes, in most situations a properly tuned and configured database will return most reads from memory.
Slashdot Mirror
You mean I'll have to have a goat on my computer? But I prefer sheep!
I do suppose that's much better than running over people!
US Ephemeral Dollar, the way the Goverment spends it!
Stupid git...
Actually, the death of Slashdot is a blessing in disguise. You see, Slashdot is entirely responsible for the current global economic crises. When a nerd or other smart person first reads this site, he or she is instantly hooked on the discourse with other nerds, even if it's just inane drivel. As more and more nerds get addicted to Slashdot, productive grinds to a halt, causing companies to fail. The happened first in North America with the dotcom crash. As ubiquitous internet access spread around the world, so did Slashdot's productivity sucking force. That is why we're now in a global recession, except for Africa where there's been an on going recession ever since an unfortunately soul laid out a stone and a stick in a /. pattern thousands of years ago. Cowboy Neal is nobody more than a drug runner for the Bilderberger Group who plan to control all the intelligence in the world with their Slashdot drug.
Like in TNG espisode #34 where an organism eats the hulls of the USS Enterprise and the IKS Pagh? Who knew they were still using windows in the 24th century!
Sailors are pissed
Aye... with the email down, we're downing the rum!
It looks like 'attack' uses GNU-style command line switches. Do you know if the source code is available?
Sincerely,
Ministry of Defence.
Only leap years. The rest are 28 days long.
Things are going to change very quickly once the depression is in full force. Those who have no knowledge will have no food. They won't have idle entertainment when all their money is going to buying the basics of life. They'll start putting a lot more energy into being productive.
You can get slightly better Isp than that, actually. For example, I get 4664 m/s vacuum Isp
DUDE!!! You must have a ton of warez!! Where can I sign up for Vacuum Isp?? My ISP suck0rs!! Im lucky if I get 3 Mb/s, but ur getting 4664!! NO FAIR!!!!1!
Hey, I'm sure some Google Vice-President is proud of the fact his kid puked up a bunch of crayons that vaguely resemble a "g".
It's no wonder why they're going bankrupt, missing headline stories like this!
First post and we've already begun to synch into the bad jokes...
Yes, it would cause a high load on the replicant server, too. But it's okay if the replicant falls behind a little bit. Once the heavy demands of the backup are complete, the replicant can catch back up. Obviously, if both machines are loaded to near capacity, this won't work -- but by then you'd already be experiencing intermittant slowdowns (increased latency) at busy times of day.
The main delay is caused by disk bandwidth regardless of the backup method. It simply bogs things down when you read gigs of data off the disk.
That's exactly the solution.
And as an added bonus, if you configure the two machines to replicate both ways, you can switch between which one is the primary at any time. This allows you to take either machine offline to upgrade software or hardware or move the machine, etc. Some highend database software may have this functionality already. And there's the MySQL Multi-Master Replication Manager at http://code.google.com/p/mysql-master-master/ for MySQL. I'm not personally aware of anything for Postgres, but it may exist (and I imagine MMM could be easily re-written for it).
Would you prefer something more poetic? Vogon perhaps?
Yeah, I'm speaking from experience with MySQL's version of the same thing. It took almost two hours for the mysqldump to complete :/
I think we're saying the same thing, just in different words. There are two things to backup: physical and temporal. First is the ability to keep everything working. That requires backup hardware and a working copy of the data. Second is the ability to access the data as it existed at a previous point in time. That requires a stable, detached copy of the data, usually stored on separate media for space and reliablity concerns.
I agree that not having a detached, stable copy of the *data* is not having a backup of the *data*. So having a second machine is definitely not a backup of the *data*. A second machine is a backup of *hardware* only. But having a backup of just the *data* is also not a *complete* backup. We've all heard stories of old media that can't be accessed because the hardware doesn't work or can't be found. A *data* backup is useless if you can't access it.
So a backup of hardware or a backup of data is indeed a backup, by definition. But neither is a *complete* backup solution, which includes both physical and temporal backups. Journalspace.com had some of the former and none of the latter.
And as long as the database can do that in a reasonable amount of time without affecting the performance of on-going database activity, that's great. But setting up a system capable of that is more complex than doing a straight file-system copy, hence "a bit tricky" in comparison, though not necessarily difficult.
And watch all your busy tables write-block and your site go unresponsive while pg_dump does its thing?
And wait for hours and hours while pg_restore executes millions of insert queries and rebuilds indices?
Sure, pg_dump (or whatever another database might use) works for tiny databases where a few seconds of latency is tolerable once a day. It's not tolerable when you're down for hours.
Keeping the database responsive when backing up a live database is what makes it tricky.
That's exactly what I'm talking about (though I didn't know the Windows parlance). The reasons for adding the slave machine are two: first, to have a hot spare should the first one go down, which is handy for doing software updates and other maintenance; and two, to avoid degraded performance during the backup. The second isn't an issue on a lightly loaded server, but on a busy box, it's a choice between keeping the box quick or having a quick backup.
Yep. The only trick is making sure your backup process completes before the log has over-written itself at the point when the backup started, and that the log is copied last. If you were backing up say 100 GB at 50 MB/s, it's going to take 34 minutes -- meaning the log better hold at least 34 minutes of updates, and many times that for a comfortable margin.
It's much simpler to create a snapshot and copy from that.
Semantics. It's a backup on the hardware level, but not the software level. It's like having two pumps at a well. Either can do the job so one is a backup, but someone can still poison the water.
What? Snapshots take at most a second. They're done on the filesystem layer, and updates are written to different blocks. Once you've finished copying the data off the snapshot, delete the snapshot and the old blocks are freed for use again. Databases often have the handy write pattern where most updates are done to the same or contiguous areas, so you usually have many hours/days before the filesystem is forced to overwrite the blocks in the snapshot if you don't delete it in time.
Any database worth its salt will keep everything synchronised to disk at all times. A query won't return unless the changes are written. The only issue can be if the OS or disk itself has buffered the writes, but transactional databases ensure consistency with an update log on disk (updates are first written to the log and another process commits those updates from the log to the database files).
And yes, in most situations a properly tuned and configured database will return most reads from memory.