I want to replicated a single database of a mongoDB-Server. There are four databases on the server:
Server A
to replicated
Server B
database 1a
database 1b
database 2a
database 2b
database 3a
-------------->
database 3b
database 4a
database 4b
Only the database 3a should be replicated to Server B.
How can I do it? Is it possible with the normal replication configuration (https://www.mongodb.com/docs/manual/replication/) and if the answer is yes, how?
I hope you can help. Thank you in forward.
Yes, it's possible... Change streaming is the solution. So, you copy changes of one database (or collection) to other server.
Short answer: this is not possible with Replication.
Long answer: Perhaps is would be possible with some crazy setup of a Sharded Cluster, because sharding is enabled/disabled per database.
Related
I am new to DB2/UDB. I have a 3 instances each instance have different number of databases below.
instance_1 - 20 databases
instance_2 - 18 databases
instance_3 - 16 databases
Totally I have 54 DBs. All are in sync now. I have developed a stored procedure for a requirement. I have to deploy this stored procedure to all 54 databases. I am doing it manually (54 times). It is very hard to do and it leads to human errors.
Can anyone suggest a tool / approach to do this process automatically.
We have a master SAP Sybase database A in country C1 and we need a read only copy of the sybase database B in country C2 (currently hosted in hyper-v). We are currently doing this backup using full and incremental backup. The problem is that it is taking too long to mail the tape and do full database restore at the site B. We have established a VPN connection and the bandwidth is not big. We can accept a few day latency. What are my options besides (using replication server) to do this database synchronisation as corporate situation do not allow spending of extra $.
Our full corporate backup data amounts to 5 TB in size.
Thanks.
Patrick
Without using Replication Server, the simplest solution is probably to use log shipping. This utilizes the transaction log from one database to synchronize another database.
After an initial dump of the Database A has been loaded in Database B, you would setup scheduled transaction log dumps, and load those dumps in Database B. After the initial load, the dump sizes would depend on the database transaction rate, so the more activity in the database, the larger the dumps will be.
A couple of things to note:
This will likely require more transaction log storage space on Database A.
Database B will not be accessible during the transaction loading time.
A good description of this and other options can be found in this SAP article on Business Continuity
My case is in SQL Server, I want to take backup of a database. The transnational data in the database is purged based on a retention period, say 90 days. The requirement is to have an archive on another server for up to 10 years, so that user can run ad-hoc queries directly on the stored data. I guess neither creating a replica nor standard backup using SSIS is not beneficial. The question is what sort of solution is the best fit with the requirement?
Try this - You can setup replication from transactional "current" database to Archive database. While setting up replication, you can configure the delete activity to NOT replicate.
Have an empty db on live server. Call it "tempo"
Every 90 days, move data from live db to tempo db
Backup tempo db and restore it on archive server
Copy data from tempo to archive database
Drop tempo db
We have two servers, A and B
on server A we have DB OPS_001 with a number of tables.
on server B we have DB XYZ with a number of tables.
We consider a project of integrating both systems and start pointing the resulting system to the tables in server B (for foreign keys/etc). We face some technical difficulties physically moving all tables from server A.OPS_001 into B.XYZ due to legacy applications that need to have connections rewritten and compiled.
Is there a way to mirror server A.OPS_001 tables in B.XYZ such a way that the performance is still acceptable (like not taking 1,2 seconds for a select on a PK)? I know acceptable is a very generic term but take in consideration around 150 users rely on those 2 databases from 9am to 5pm.
I've tested linked server views but it's very slow.
Just so you know, A is a SQL Server 2000 and B is SQL Server 2008.
EDIT:
Size of the source DB is 220 tables and the file itself around 14 GB.
The solution was to migrate the database to the same server and since the databases were extremely tightly coupled, they should be merged together and form a single database with relational integrity.
Say you have 2 database servers, one database is the 'master' database where all write operations are performed, it is treated as the 'real/original' database. The other server's database is to be a mirror copy of the master database (slave?), which will be used for read only operations for a certain part of the application.
How do you go about setting up a slave database that mirrors the data on the master database? From what I understand, the slave/readonly database is to use the master db's transaction log file to mirror the data correct?
What options do I have in terms of how often the slave db mirrors the data? (real time/every x minutes?).
What you want is called Transactional Replication in SQL Server 2005. It will replicate changes in near real time as the publisher (i.e. "master") database is updated.
Here is a pretty good walk through of how to set it up.
SQL Server 2008 has three different modes of replication.
Transactional for one way read only replication
Merge for two way replication
Snapshot
From what I understand, the slave/readonly database is to use the master db's transaction log file to mirror the data correct?
What options do I have in terms of how often the slave db mirrors the data? (real time/every x minutes?).
This sounds like you're talking about log shipping instead of replication. For what you're planning on doing though I'd agree with Jeremy McCollum and say do transactional replication. If you're going to do log shipping when the database is restored every x minutes the database won't be available.
Here's a good walkthrough of the difference between the two. Sad to say you have to sign up for an account to read it though. =/ http://www.sqlservercentral.com/articles/Replication/logshippingvsreplication/1399/
The answer to this will vary depending on the database server you are using to do this.
Edit: Sorry, maybe i need to learn to look at the tags and not just the question - i can see you tagged this as sqlserver.
Transactional replication is real time.
If you do not have any updates to be done on your database , what you need is just retrieving of data say once a day : then use snapshot replication instead of transactional replication. In snapshot replication, changes will replicate when and as defined by the user say once in 24 hrs.