September 30, 2003 at 1:14 pm
We provide a SQL server database for our clients data when they use the application my workplace has developed.
They want to cluster their SQL Server.
Rather than using the built in functionality from Microsoft natively, they are going to use a program called SQLUP! to do the clustering (which uses the same microsoft clustering technology) and provides a custom user interface i guess.
The issue is this: the SQLUp! program will be adding new columns to any table without a PK. Does clustering using the native Microsoft technology do that also?
new columns added without the developers knowledge could potentially doink sql statments and stored procedures...especially insert statements if it 'forgot' to put in a default value for example, or an insert statement that did not define all the fields for the INTO clause; I'm trying to find out whether this is a common clustering practice, or just something they may have added, possible to track changes or something.
I know there is a statement in the contract that says the end user shall not change the schema, and I'm wondering if this is an issue to throw on managements plate.
To answer my own question slightly, I already have two other clients who have clustered servers, and when I restore a backup from them for debugging purposes, I've never seen any extra columns in those situations.
Thanks all.
Lowell
Lowell
September 30, 2003 at 1:23 pm
MSCS does nothing to database tables. I have no idea why clustering should do that, unless you mean something other than what I do when you say "clustering". Maybe if you mean a federated database, in which you create distributed views and need a way to ensure that each server's table section is indexed properly?
September 30, 2003 at 1:43 pm
I'm certainly no expert on the issue, but from what I gather, this program "clusters" two SQL servers, but they do not need to share the same storage location...it allows replication over the internet, and to two differnet machines which are not identical in configuration. IAs I read more into it, I think it is more of a fancy replication program, and needs the PK or newID() column to track updates /inserts/deletes. it uses a stored procedure it created to update the changes, so I'm assuming now that the program simply reads the transaction logs and performs the auto updates every X seconds, as well as some clustering functions...if one server to to die, it would handle the passing over of data to the other server on the cluster.
Lowell
Lowell
September 30, 2003 at 2:56 pm
It depends on whether you want both servers to be live or whether you can deal with one being a "hot spare" -- like a distributed MSCS cluster. For the former you need to compare it to a full "replication" system and I think that Microsoft's version does have requirements on table structure.
If your backup server can be kept offline you can try log-shipping or a product like Veritas's storage exec as a comparison. These both (as I understand it) set you up so that an offline server can be started immediately a failure occurs (perhaps with a slight data latency to the last shipped log file). Neither of these products (again, as I understand it) will have any constraints on your database as you're basically just bringing a backup online when the primary fails.
(I liked Storage Exec when I researched it, but I've not implemented it as immediate recovery to another site is not a big issue for me. What it does is put in a driver between NTFS and the disks that catches all writes to the volume you're watching and sends them to a client. The client then reconstructs the exact files you're watching, byte by byte, second by second. This client action prevents SQL from locking the log and data files, so you can't have the backup database online as well as the master.)
September 30, 2003 at 5:28 pm
SQL Up "simulates" a cluster via SQL replication - thats why you need the guids, to support replication. I've seen a demo, it seemed to work very well. Note that based on what I saw, you end up having an extra db per "clustered" db on each server to hold the replication metadata it moves back and forth. The advantage to a system like this is you dont have to have specific hardware and you can "cluster" over a long distance - like across the world if you want.
Andy
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply