When you restart the master server for the production database, what will the application servers query?
The next node in the cluster? If this is a critical infrastructure system where time is money (or lives, or whatever) then you DO have a redundant highly available architecture, right?
The fact that "all systems develop runtime cruft over time" is the problem.
This is only part of the problem (and I'm not convinced it is fact). Other problems are that hardware has a finite lifetime (be it however long), and we never have complete control over the environment, no matter how much we spend on the space.
No matter how how bulletproof the system is, nothing is completely immune to failure - I do, however, rebut the notion that rebooting and kernel updates are inevitably linked. Something/will/ crash, and murphy dictates that this will not happen when you plan it - so it is best to plan accordingly. This is a trait of a good sysadmin. This makes a reboot after a kernel upgrade a sensible precaution - but not inevitable, and perhaps the reboot is better aligned with a disaster recovery planning operation.
Ultimately, as previously noted, the major advantage to this is not skipping an otherwise obligatory reboot, rather, it is being able to segregate upgrades and reboots, and not be forced to combine those activities. Both are important, but more control of potential downtime activities is a good thing.
In a company large enough to support it, there should be a manager with a technical background who can understand what the engineers are saying and provide occaisional insight or recommendations, who would then translate that into 'business speak' for management who lacks such a background.
That is not to say that technical management should necessarily have the same specific background or skillset as the engineers who report to them, but they should have enough to understand tecnical jargon, and specific requests. There is nothing more frustrating than trying to explain a complex technical issue to someone with no background, unless it is a technical manager who feels that they can do everything you can, but better (if they only had the time).
What I've seen work best is technical management with 'generalist' backgrounds, with reports who have more in depth, but specific, backgrounds.
someone with perl experience, you might try rewriting something like Spam Assassin to search for appropriate keywords and route the mail accordingly.
Then again, I usually prefer the in house custom solutions, because when you have them finished, you end up with something better suited to your needs, and you have a strong familiarity with the system when something goes wrong.
There are a number of problems with that though.
on
Privacy in the Woods?
·
· Score: 2, Insightful
What happens when I go out hiking and pass sensors 1 - 4 (of 10, for example), turn around, and head back? Is the system going to be implemented in such a way that it will recognize 'turn arounds' - or will it just assume that there are two hikers lost between points 4 and 5?
Slashdot Mirror
When you restart the master server for the production database, what will the application servers query?
The next node in the cluster? If this is a critical infrastructure system where time is money (or lives, or whatever) then you DO have a redundant highly available architecture, right?
The fact that "all systems develop runtime cruft over time" is the problem.
This is only part of the problem (and I'm not convinced it is fact). Other problems are that hardware has a finite lifetime (be it however long), and we never have complete control over the environment, no matter how much we spend on the space.
No matter how how bulletproof the system is, nothing is completely immune to failure - I do, however, rebut the notion that rebooting and kernel updates are inevitably linked. Something /will/ crash, and murphy dictates that this will not happen when you plan it - so it is best to plan accordingly. This is a trait of a good sysadmin. This makes a reboot after a kernel upgrade a sensible precaution - but not inevitable, and perhaps the reboot is better aligned with a disaster recovery planning operation.
Ultimately, as previously noted, the major advantage to this is not skipping an otherwise obligatory reboot, rather, it is being able to segregate upgrades and reboots, and not be forced to combine those activities. Both are important, but more control of potential downtime activities is a good thing.
In a company large enough to support it, there should be a manager with a technical background who can understand what the engineers are saying and provide occaisional insight or recommendations, who would then translate that into 'business speak' for management who lacks such a background.
That is not to say that technical management should necessarily have the same specific background or skillset as the engineers who report to them, but they should have enough to understand tecnical jargon, and specific requests. There is nothing more frustrating than trying to explain a complex technical issue to someone with no background, unless it is a technical manager who feels that they can do everything you can, but better (if they only had the time).
What I've seen work best is technical management with 'generalist' backgrounds, with reports who have more in depth, but specific, backgrounds.
You may want to try here.
Yes, it is a good thing.
/all/ a good thing.
It pays the wages of many of the people posting here, and enables you to post your inane little comment, as well.
Wait. Maybe it isn't
someone with perl experience, you might try rewriting something like Spam Assassin to search for appropriate keywords and route the mail accordingly.
Then again, I usually prefer the in house custom solutions, because when you have them finished, you end up with something better suited to your needs, and you have a strong familiarity with the system when something goes wrong.
What happens when I go out hiking and pass sensors 1 - 4 (of 10, for example), turn around, and head back? Is the system going to be implemented in such a way that it will recognize 'turn arounds' - or will it just assume that there are two hikers lost between points 4 and 5?