Instead of working, I blog.

I'm sitting at home really sick today, so do me a favor and just assume I would've said something really inspiring and groundbreaking about backup or benchmarking.

Hopefully I'll be back online tomorrow.

I was talking to a vendor the other day, and he was saying that he was trying to do a 3rd party solution that would allow you to mirror a single DB to several servers at once. I've officially coined the phrase MultiCast Mirroring. I think this is the next logical step in the mirroring process, and while it wouldn't be practical to use it with safety on, you could use it to keep several types of systems more or less in synch. Of course, I would expect that at least one of the mirroring sessions would have safety on, but not all.

I know what you're all thinking... if you need to do something like that then why not just use replication? Well, that's actually a significant question and as we've all seen, repl and mirroring aren't the same thing at all. They're different approaches to similar problems, but they do have major differences. I'm not going to go into all the tired arguements right now, but most of us know what they are. Let me just say that repl adds a complication that doesn't need to be there.

One interesting thing is that I'm going over the architecture of what would make this possible, and under the covers, it would need to look a lot like repl. To avoid any reading conflicts, etc with the primary log, you'd prob end up shipping the single log to like a log distribution server where any server that wants to attach itself to it as a mirror can do so. So now we're looking at kind of a publisher/subscriber type of method. It's still easier to keep up with than repl. though.

Anyway, this is all just my rambling, but it would still be interesting to see something like that.