I am trying to switch to Redis database and during the replication stage I got some issues.
The problem is that I want to have a single database (central) to which the other separate databases (different data in each one) automatically send the data to.
In the documentation I find that normal replication sends data from one central db (master) to the slaves not the opposite.
Related
I have a requirement where the client database changes should be sync with the server (centralized). All clients use only SQL Server Express where as the server is of SQL Server 2008 R2. Do we have any way to do this without Microsoft Sync framework? With sync framework, all data starts from the beginning which is taking longer time.
Without knowing what acceptable latency is, what the network latency/reliability is, whether clients are connected/disconnected, and whether or not changes made at the clients need to be sent back to the server, assuming you want to send incremental changes, you have options database and log backup/restore, transactional replication and merge replication. There may be more, but those are the more common solutions that will synchronize two servers.
If you are looking for bi-directional data flow, then merge replication is the appropriate solution.
Merge replication is typically used in server-to-client environments. Merge replication is appropriate in any of the following situations:
Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers.
Subscribers need to receive data, make changes offline, and later synchronize changes with the Publisher and other Subscribers.
Each Subscriber requires a different partition of data.
Conflicts might occur and, when they do, you need the ability to detect and resolve them.
The application requires net data change rather than access to intermediate data states. For example, if a row changes five times at a Subscriber before it synchronizes with a Publisher, the row will change only once at the Publisher to reflect the net data change (that is, the fifth value).
Let's have a classic server-side RDBMS (Oracle/MS SQL/MySQL) and a client side embedded database (e.g. sqlite). We want some tables kept in sync between client and server.
Each server-side table to sync has its counterpart in client-side with the same schema (...or at least similar considering the different data types supported by the database engines). Moreover each table has a timestamp column updated by every update operation.
How can we collect the rows that are updated either server or client side since the last sync efficiently? Efficient meaning
with low bandwith usage, e.g. not sending entire tables back and forth
in a resource friendly way so that the syncing process can be utilized frequently
I can't understand the difference between transactional replication and merge replication.
This is my scenario:
In an organization I have a SQL server which need to collect information from different sql servers which are located in different parts of organization or around the city and some report will create according to gathered information.
Data in different SQL servers update every 5 or 6 minutes.
I don't know should I use transactional or merge replication?
Transactional replication delivers incremental changes from a single publisher to one or more subscribers.
Merge replication brings changes from multiple subcribers together into a central publisher.
It sounds like you'll want merge replication in your scenario.
Merge. Each site is a master of it's own data.
Transactional is one way usually.
You need to share information so merge it is...
Edit, after comment
In which case, yes. Your question implies reporting at each location
However, for performance, I'd consider pushing all updates into a queue using a trigger and Service broker. This way, the write to the remote server is decoupled from the local transaction.
Hi can any body tell me what is use of replication in sqlserver2005.
backup and replicaton looks same?what is diference b/w them
Backups are exactly that: backups. They enable you to recover the data if something bad happens.
Replication is another beast entirely. It basically distributes the data across multiple nodes so that each node has a complete, (close to) up-to-date copy of the data.
There are a number of reasons why you would use replication including, but not limited to:
High availability so that, if one node goes down, other nodes can still service requests.
Geographical distribution, meaning your data can be placed close to those that need it. Clients in Belarus don't need to go all the way to Montana to get the data if you maintain a local replica in Belarus (or somewhere close) - this is for performance. You may have 10,000 clients in Belarus - it's quicker to send one copy over than have all 10,000 request data [although this depends on how often they request data].
Prioritization. If your reporting users (bank management) have a lower service level agreement than your customer-facing staff (bank tellers) [and they should], you can put all the management onto a replica so as not to slow down the primary copy.
Replication is used for a different purpose, for example to make reports without putting that load on the 'real' database.
Replication increases system availability. If one set of database is down, you can serve out of replica.
Backup saves you from catastrophic errors such as human error that dropped the production database. Note that in this case, replication won't save you as it will dutifully replicate drop command.
SQL Server replication is the process of distributing data from a source database to one or more destination databases throughout the enterprise.
Replication is a great solution for maintaining a reporting server.
Clients at the site to which the data is replicated experience improved performance because those clients can access data locally rather than connecting to a remote database server over a network.
Clients at all sites experience improved availability of replicated data. If the local copy of the replicated data is unavailable, clients can still access the remote copy of the data.
Replication: Lots of data, fast and most recent.
Backup/Restore: Some data, perhaps a bit slower, and a specific point in time.
Replication can be used to address a number of different scenarios as detailed below.
Just to be clear however, Replication is not the same as Database Backup
Scenarios:
Server to server: Replicating Data in a Server to Server Environment
Improving Scalability and Availability
Data Warehousing and Reporting
Integrating Data from Multiple Sites(Server)
Integrating Heterogeneous
Data Offloading Batch Processing
Server to client: Replicating Data Between a Server and Clients
Exchanging Data with Mobile Users
Consumer Point of Sale (POS)
Applications Integrating Data from
Multiple Sites (Client)
For a full overview of Microsoft SQL Server Replication see the following Microsoft reference.
http://msdn.microsoft.com/en-us/library/ms151198(SQL.90).aspx
Choose the track that is most appropriate to you (i.e. Developer / Architect) and all shall be revealed :-)
In the business I work for we are discussion methods to reduce the read load on our primary database.
One option that has been suggested is to have live one-way replication from our primary database to a slave database. Applications would then read from the slave database and write directly to the primary database. So...
Application Reads From Slave
Application Writes to Primary
Primary Updates Slave Automatically
What are the major pros and cons for this method?
A few cons:
2 points of failure
Application logic will have to take into account the delay between writing something and then reading it, since it won't be available immediately from the secondary database
A strategy I have used is to send key reporting data to a secondary database nightly, de-normalizing it on the way, so that beefy queries can run on that database instead of locking up tables and stealing resources from the OLTP server. I'm not using any formal data warehousing or replication tools, rather I identify problem queries that are Ok without up-to-the-minute data and create data structures on the secondary server specifically for those queries.
There are definitely pros to the "replicate everything" approach:
You can run any ad-hoc query on the secondary, since it has all of your data
If your primary server dies, you can re-purpose the secondary quickly to take over
We are using one-way replications, but not from the same application. Our applications are reading-writing to the master database, the data gets synchronized to the replca database, and the reporting tools are using this replica.
We don't want our application to read from a different database, so in this scenario I would suggest using file groups and partitioning on the master database. Using file groups (especially on different drives) and partitioning of files and indexes can help on performance a lot.