3

SQL Server Mirroring is part of the core engine. When you setup mirroring, SQL Server enables a TCP endpoint to support the flow of log records from the primary server to the secondary server, and to optionally connect the witness server. Mirroring actually consists of sending log data from the primary to the secondary. Since Mirroring can be configured ...


3

This is an older question, but there are some things that were not explained well and this will hopefully shed some light. The how to shrink was answered, mostly, but this will explain the "why" part of what you are actually doing. Backups, specifically log backups, do several things. The data is written to disk as a backup set to be used or discarded ...


3

In my experience, detach/attach is the fastest method. The bottleneck would probably be how quickly you could copy the files across the network. Assuming the two databases have identical Windows accounts (if you're using SQL accounts you may have to update SIDs), you could probably use something like this script that I have laying around from before I ...


2

You'll get that error if you try to run the alter database [yourdb] set partner... statement at the primary first. You need to run that alter statement at the secondary and then run it at the primary. So, in the link that you pointed to, it seems that the last thing in step 10 hasn't been run yet.


2

You've created an ENDPOINT on the witness, right? Read this on how to create a witness endpoint. Check that there isn't either the Windows firewall or a network device blocking the endpoint port on either principal to witness or mirror to witness. I always like to use: telnet hostname port To test that the ports are open. You should get a connection ...


1

I depends on what software you're dealing with but... Usually (historically speaking) you would not want to put database storage on a NAS, because that would mean using a network filesystem like NFS or CIFS, etc... which could cause all sorts of data integrity and performance problems. There is still iSCSI though which is not a filesystem., but it still ...


1

Probably too late, but, I would suggest spinning up a new 10xl unecrypted RDS from a snapshot, and then create a new blank 10xl encrypted RDS. These faster RDSs will hopefully speed it up. After you have the encrypted RDS, snapshot it, and then restore to whatever normal size RDS you use. Also, try to do the export and import to an EC2 instead of your local ...


1

Your intuition is likely correct. You can verify that the SIDs are different between your nodes by running: select name, sid from sys.server_principals on each node and comparing them. As far as how you're supposed to keep them in sync, do so at creation time (unfortunately, there's no way that I know of to change the SID post facto). That is, the create ...


1

As you describe your application, I am afraid it will not be very easy to 'mirror'. Especially if the data has to change in real time (as it does with GDocs). I am afraid MySQL is not a very good database for such deployment. Filesystem is yet another trouble. The best thing you could do in long term, is probably redesigning the whole thing to use better ...


Only top voted, non community-wiki answers of a minimum length are eligible