Steve Jones - SSC Editor (8/14/2014)
Brandon J Williams (8/13/2014)
My point is that replication novices are quick to point the finger at replication when it's not replication that is the problem.We actually haven't done much in the way of getting a stable replication environment, it just works. Sure, we've read BOL, but as far as getting it stable, that's it.
You're conflating your experience with the capability or robustness of replication. I've had to be stable in places, I've had it inexplicably fail. Certainly some of the failures have to do with a lack of bandwidth, or maybe disk space, or networking, or data, or something else.
However that's where replication is brittle. It will fail with things that shouldn't cause it to fail.
Replication is not brittle. When it fails, due to something like lack of bandwidth, disk space, networking, or data, that is not replication's fault. Any other piece of software could fail under those circumstances. Replication is no different.
Just because it hasn't for you, doesn't mean it can't or won't.
That is true. The learning curve with replication can be steep, and while there is usually one way of setting up replication correctly, there are many ways to set it up incorrectly.
The fact you reinitialize subscriptions leads to my point that it has plenty of room for improvement (along with other features).
I think you misunderstand. There are publication and article properties, that if changed, require that the snapshot be regenerated and/or subscriptions be reinitialized. This is no secret, it is spelled out in BOL. So what we have in that case is the need for a maintenance window. The ability to reinitialize subscriptions quickly has to do with shrinking that maintenance window down as small as possible.
The impression that replication is brittle is just inaccurate. Just like any other technology, its concepts must be understood to avoid common pitfalls.