Earth to Microsoft: You Blew It (again)
by Ted Wallingford
I'll be the first to admit that I'm not an experienced DBA, which is probably why I've ended up becoming a VoIP guy. Yet I do, in the course of consulting, periodically deal with database stuff. A ubiquitous as Microsoft is, SQL Server is everywher. It seems, no matter how hard one tries to live outside the Redmond Control Bubble, it's impossible to avoid the occassional collision course with Microsoft Enterprise Manager (SQL Server's administration tool).
Over the last few weeks, a client of mine in the news publishing business has been trying to build high-availability and disaster survivability into his network. When I read that SQL Server 2005 was going to have built-in database mirroring, I said, "Great, we'll just migrate to it." With database mirroring in SQL Server 2005, I'd be able to implement an instant hot-failover solution for each of my client's three SQL Servers.
Of course, that was before September 19, when Microsoft quietly announced (so quietly that the press didn't pick up on it until a week later) via one of its employee's blogs that they were dropping the database mirroring feature from the upcoming SQL Server 2005 release. I was disappointed, but not surprised. The Microsoft has a nasty tendency of pulling off last-minute, understated product roadmap changes that have a devestating impact. (When Windows 95 was in beta, the Corel-Draw add-on package published by my employer worked flawlessly until the second-last release candidate--then, it needed a complete rewrite and took a year to be made 95-compatible. But I digress.)
Nevertheless, I figured on building a fault-tolerance solution for my client that didn't require SQL Server 2005. I looked at shared fiber channel storage, transactional data replication, and a number of other solutions, when the question of the day just hit me:
Why isn't there a file system that implements real-time, networked data mirroring at the file-system level?
Maybe there is, and I'm just not aware of it. Maybe it's an impractical idea because of issues with network bandwidth and the asynchronous nature of disk-based file systems. I don't know. Hey I told you I wasn't a database guy.
What should my solution be?
It sounds like you want a SAN. But you already mentioned shared disk storage... so I'm not sure why that's not good enough.