We want to use Change Tracking to implement a two-way sync between a SQL Server 2008 Enterprise/Standard instance, and an Express 2008 instance.
When we read the remote changes, and then make the adjustments on the local server, how can we keep those statements from being change tracked? I foresee endless loops of one server tracking a change, then the other making the change and also tracking the change, the other server making the change, etc.
Disabling change tracking on that table while performing the sync operations could potentially miss changes from other processes on that table, so I don't think that's the answer.
Is there a way to disable change tracking on a per-statement or per-transaction basis?
EDIT: I discovered the WITH CHANGE_TRACKING_CONTEXT command, so I might be able to use that to specify when the changes are performed by the sync code so that the sync code itself won't pick those up and use them.
Change Tracking isn't really meant to be used as bi-directional replication. You should figure out some way to determine the instance where the change was actually made, then your "replication" code should be able to ensure that the changed rows on the replicated server do not wrap back to the original server again.
Related
Situation:
I've just deployed the first version of my website (in PHP with
MySQL database). I now need to move to version 2 of my website.
I typically build my website on localhost before moving it to the production server
I now want to restructure my database. But I'm not clear how to do this without losing / corrupting existing user data.
I'm worried that WHILE I'm making the above changes, a user may try
to make edits to the database.
Questions for you
Let's say I restructure my database in localhost. How do I duplicate
this restructuring on the live server? Do I need to run every query
on both localhost and production servers? (Seems very inefficient -
is there a better way to do this?)
How do I make sure that while I'm restructuring the database, the
sanctity of the data is not harmed (i.e. how do I make sure the
"version" of the database does not change until I finish my job?)
You create a "migration script" in sql that collects all queries required to migrate a database between two states. You try that how often required in your development environment and once on the production environment.
During that migration of the production environment you enable a "maintenance mode" that prevents any changes to the data being made and clearly states so to the user. Be transparent here. Two variants are in use:
you block all requests and temporarily replace the site by a "maintenance sign", this is typically done if the migration only takes a very short time. If that is not sufficient, then
you have to implement a read-only or maintenance mode into your logic rendering all data as read-only. Again: be transparent to you users in this.
If that is all too much hacking, then you might want to learn from the "big players" who never manipulate running systems at all, but only switch between instances, often a pool of instances. So you prepare a second, new system and only switch to that at a given point in time. Still you have to take care of a read-only period to allow data synchronization, but the switch itself is fast and reversible.
For security purpose, we will create a database log that will contain all changes done on different tables on the database, to achieve this we will use triggers as stated here but my concern is that if the system admin or anyone who has the root privilege changes the data on the logs for their benefit it will then make having logs meaningless. thus, I would like to know if there is a way for me to prevent anyone and I mean no one at all from doing any changes on the logs table, i.e dropping the table, updating, and deleting a row. if this is even possible? also in regards to my logs table, is it possible to keep track of the previous data that was changed using the update query? I would like to have a previous and new data on my logs table so that we may know what changes were made.
The problem you are trying to fix is hard, as you want someone who can administer you system, but you don't want them to be able to actually do something with all parts of the system. That means you either need to administer the system yourself and give someone limited access, trust all administrators, or look for an external solution.
What you could do is write your logs to a system where only you (or at least: a different adminsitrotor then the first) have access.
Then, if you only ever write (and don't allow changes/updates and deletes) on this system, you will be able to keep a trusted log and even spot inconsistencies in case of tampering.
A second method would be to use a specific method to write logs, one that adds a signed message. In this manner you can be sure that the logs have been added by that system. If you'd also save (signed) message of the state of the complete system, you are probably going to be able to recognize any tampering. The 'system' used for signing should live on another machine obviously, making it somewhat equivalent to the first option.
There is no way to stop root access from having permissions to make alterations. A combination approach can help you detect tampering though. You could create another server that has more limited access and clone the database table there. Log all login activity on both servers and cross backup the logs between servers. also, make very regular off server backups. You could also create a hashing table that matches each row of the log table. They would not only have to find the code that creates the hash, but reverse engineer it and alter the time stamp to match. However, I think your best bet is to make a cloned server that has no net login. Physical login only. If you think there has been any tampering, you will have to do some forensics. You can even add a USB key to the physical clone server and keep it with a CEO or something. Of course, if you can't trust the sysadmin's, no matter what your job is very difficult. The trick is not to create solid wall, but a fine net and scrutinize everything coming through the net.
Once you setup the Master Slave relationship, and only give untrusted users access to the slave database, you won't need to alter your code. Just use the master database as the primary in your code. The link below is information on setting up a master slave replication. To be fully effective though, these need to be on different servers. I don't know how this solution would work on one server. It may be possible, I just don't know.
https://dev.mysql.com/doc/refman/5.1/en/replication.html
Open PhpMyAdmin
open the table
and assign table level privileges on the table
Is there anyway you can stop a DDS? I have a process that adds a .pdf in 400 different folders. I was just wondering if there way anyway to stop it because sometimes it interferes with other things on the server I'm working on it and it slows it down significantly.
There's no supported way to do this. There is a hack you can try, but it involves manipulating the tables in the ReportServer database, which is unpredictable at best. Here are the steps:
Stop the SSRS server. This will make it quit sending new subscriptions, but it doesn't actually stop the DDS.
Find the relevant row in the ActiveSubscriptions table.
Delete all of the rows in the Notifications table with an ActivationID that corresponds to the ActiveID in ActiveSubscriptions.
Delete the row in ActiveSubscriptions.
Restart the SSRS server
Any subscriptions that SSRS had already queued up with the SQL Server Agent will still be processed, but it should stop sending new ones. As I said, this is a hack, and it's difficult to say what else you might break by doing this.
I was looking for a better mechanism for notifying my desktop clients that a sql server table has changed. Exclude the option of an app server tier, I'm looking at solutions that fit into the existing thick client->Sql server model. I'm familiar with triggers and polling, but was hoping for something a bit smarter.
One option seems to be SqlDependency. I'm looking at that at the moment, but have seen a few mentions that it has "restrictions" and may be "unsuitable" for large numbers of changes. I've not found a lot of information on that, or many recent code examples.
What are you using for notification that a sql server table has been amended?
Unless you have a service, ie all chnages to tables go through it, then you are down to polling or dependancy. All dependancy does is hook into sql servers own table change code and fire a change event. The underlying mechanism is very simple, and can get swamped by a large number of changes, attempting to rationalise the changes in the event handler is problematic at best.
You might get somewhere with triggers to a "communications table", where you could add the rationalisation logic, then use dependancy from there.
So instead of detecting a simple change to column1 in table1 you trigger an insert to an event record in your comms table.
It's going to be a PIA because you've excluded an app server tier, you've also drastically constrained your options for doing something efficient and nice.
I am moving to a new server and thinking about how to keep my 2 MySQL server data consistent is causing me to lose both sleep and hair.
I was thinking about using a Master-Master setup to ensure that I lose nothing in the process. How viable is that. Any potential gotchas?
Why does the old server ever need to be aware of data written to the new server? For this reason, make it a master-slave setup.
You do have to deal with the same type of configuration, for instance.. make sure the old server only uses odd id's, and the new server only uses even id's.
As soon as you shut down the old server (master), make sure nobody can write there anymore.
I'm assuming your entire website uses 1 server for both the DB and the webhosting. If this is the case, I want to add the following:
Don't rely on DNS to migrate your site, as this can take a very long time for certain users.
Consider the following:
old.example.org is the site on the old machine
new.example.org is the site on the new machine.
www.example.org is a CNAME to old.example.org.
When you do the cutover, you will perform the following steps:
The old DB server is shut down, or set to read-only.
www.example.org becomes a CNAME to new.example.org
old.example.org should now host a website that automatically redirects people to new.example.org.
This means that your users might for a while browse the url new.example.org directly. When the DNS is fully propagated your users will no longer be redirected, and automatically hit the new server when using www.example.org.
If you have a low-traffic site.. this can be much easier.. Simply point your old application to use the new MySQL database. Sure, it might seem a bit crazy to connect to a mysql server over the net; but if you're not dealing with too much data this is so much easier than any other solution..