Questions[database-mirroring](server)

Has anyone copied or restored contents of one Azure Storage Account to another? We have created a PowerShell script using AzCopy to do this. But, the storage account that has over 5,000 containers (~350GB) data taking more than 13 hrs with some data failed to copy. We are not able to use GRS option due to application limitation. Anyone have any tips or suggestions on this?

Note: Both storage accounts are in the same Subscription and same tenant. AzCopy is working , but it is taking very long time. We are looking if there are any alternative options to copy/transfer the data little quicker.

I have two different MySQL instances that I would like to 'slave' to a third instance. (so I can do easy joins on the third instance)

eg.

mysql1> show databases
db1
db2

mysql2> show databases
db3
db4

mysql3> show databases
db1
db2
db3
db4

I've looked at maatkit (percona toolkit) pt-table-sync but people say it can corrupt data. (It apparent removes and re-adds data to generate inserts)

pt-archiver sort of works for 'snapshots', but db1 is approximately 6GB and copying the whole thing over is a lot more data than really needed. The real time updates are only about 100MB a day.

The natural concept to me would be to allow mysql3 to run as a replica slave of BOTH mysql1 and mysql2, but that doesn't seem to be an option in MySQL

Tungsten Replicator seems to allow for this type of data sync, but it seems a bit unwieldy to configure and I'm concerned about reliability.

Does anyone have other solutions they've used for this problem?

I need to replace the old database in our test environment with a fresh copy of the production database.

The test environment is actually comprised of two instances of the test database, on 2 different servers, in a mirroring configuration (it's got mirroring because production has mirroring, and the client wants the test environment to be just like production).

I thought this would be a simple matter of:

• Getting a backup (the .bak file) of the production DB
• Temporarily disabling the mirroring for the test DBs
• Overwrite (i.e.: restore) them from the (prod) backup
• Re-activate mirroring

But apparently this isn't nearly enough hoops to jump through. After wrestling with it for a day (permissions problems, cryptic errors, problems that go away if you restart SSMS (seriously), I'll spare you the full list...) I finally got the new DB restored onto both the principle and mirror instances of the test DB.

However, somewhere along the line SQL Server abandoned the mirroring configuration settings, so I right clicked on the principle, chose mirroring, and went right through the security wizard. When I clicked "Finish" at the very end of the security wizard, it did it's thing and I got the screen that reports that everything was set up successfully ("Configuring endpoints" - "Success"). Immediately after that is another window asking if I wish to start mirroring, however, clicking start on that window, I get the following SQL Server error:

An error occurred while starting mirroring.

Database "3DSS_TEST" is not configured for database mirroring. (Microsoft SQL Server, Error: 1416)

So I'm getting "Mirroring is configured successfully!" Then, as part of the same process, "mirroring can't start because you didn't configure it!" :(

Any ideas? Anyone seen this before, or know how to tease out a more useful error message or other info?

Update: Solved
As Brian says below, I'd restored the mirror database with the wrong recovery option, the correct way was:

RESTORE DATABASE [MyDb]
FROM disk = 'C:\TEmp\MyDb_LIVE_Prod_backup_2010-06-18_for_test_server.bak'
WITH
REPLACE,
NOrecovery /* This should be 'norecovery', my problem was I used 'recovery' */

Thanks!

An architect in our company has designed a solution based on 64 bit SQL2005 Standard edition synchronous mirroring between a physical (4 quad core, 32GB RAM) server and a virtual DR server (4 virtual CPUs with 16GB RAM) in two geographically remote data centers with a witness server (1 virtual CPU). Storage is Enterprise class SAN in both data centers.

The front end app is web facing with mixed read/write usage.

As a DBA (who wasn't consulted at the design stage) I'm worried this configuration has been designed with minimizing redundancy as the main criterion and that it's not going to work as a real world solution - network latency and performance of the virtual box will cause unacceptable response times? And even poorer performance if a fail-over is invoked.

Does anyone have experience of a similar set up?

This isn't a how-should-I-do-this question, just to set the stage. It's a what has your experience been? Please read through the whole question before quickly replying.

I spent the day yesterday teaching the current round of SharePoint MCM (Microsoft Certified Masters - see here) students all about high-availability technologies in SQL Server, plus how the SQL log/recovery/backup/restore work. This is really important as under every Enterprise-class MOSS installation is an Entreprise-class SQL Server hidden away, usually without a DBA. Kimberly teaches them a day of database maintenance on Friday (a kind of narrowed down version of the first week of the SQL MCM which we teach).

We were discussing the possibilities around using database mirroring to provide high-availability to SharePoint databases, and the relative pros and cons. Now, I know database mirroring to it's lowest internal depths, as I used to own it while at Microsoft, so no need to point out behaviors and idiosyncracies in your replies. I also know the various caveats and guidelines in the mirroring whitepaper from the SharePoint folks, and yes, they are just generalized guidelines not hard-and-fast rules.

My question is this: I'd like to hear from anyone who's implemented database mirroring for SharePoint and whether you found it worked for you, or you crashed and burned. In particular, how did you find the failover behavior worked for you? Did you end up with some database principals on one server and some on the other, effectively splitting your farm and making it unusable until manual intervention failed everything over to one server? Did you use it for local or remote HA? And so on.

Any replies will be gratefully received and will help broaden the knowledge base around marrying these two technologies, and I'll feed stories back into the SharePoint product group, and the future MCM rotations I teach as well.

Thanks!

[Edit: PS I'll put together a blog post about experiences and guidelines to this over the weekend too]