Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

System databases + replication.

Status
Not open for further replies.

mizzy

IS-IT--Management
Jun 28, 2001
277
AU
Hi,

I'm preparing for an upgrade to R5 (I know) from 4.6 (don't ask). As such I have been trying to understand as much as I can of 4.6 before I try to upgrade.

One thing that is really really confusing are the system databaes(not names.nsf its ok). Databases like statrep and events4 are driving me nuts. These databases have replicas on all my servers (11 servers). However some of these replicas are differnt from each other. They contain different data and even the ACL's are different! I thought replicas were well replicas, you know are exactly the same.
I did try to do a manual replication of statrep between two servers but that went a bit crazy. I go some message about reversing once only replication or something like that.

Are these databases special in that they do not replicate as names.nsf or an ordinary application database replicate?


Maybe its over the years our domain has become a right mess or is this how things should be.

Any help appreciated
 
Hi!

I think your last statement about the "mess" is closest to the truth!

These databases are not different in fact. They replicate like any other database.

Also: not every "system database" needs to replicate. Some only contain data that is usefull on the server they are on. But the database for the Administration Requests for example should replicate.

However: replication is determined by many things:

1/
The replication settings of the database itself.
Here you can define what will be replicated and how, or even disable replication.

2/
The replication setup on the servers.
On your servers you can define which databases will replicate when replication occur. Most organizations let everything replicate, but some do not to save bandwidth.

3/
The ACL of the database.
The ACL on each replica can be set different if you want to.
If the ACL is not correct, then it is possible the database will not replicate because the server has not enough access to it.
You can use the option: "enforce a consistent ACL in all replica's" that you find in the Advanced section of the ACL to make sure all the replica's have the same ACL.

In your case I would start by examining the connection documents on the server to see what is replicating and when.

Then make sure all these databases have the servers in the ACL with manager and delete rights. After that use enforce consistent ACL option on all of these databases.

Then replace the design with the same 4.6 template on each server to guarantee they all have the same design.

Then check the notes.log on your servers to see if there are any errors when replicating.

Once the mess is cleaned up you can upgrade to R5.
Make sure you test your important databases in an R5 environment first before upgrading, and start with the main administration server first.

Good luck!


Kind regards,

Dominik Malfait
dominik@amazingit.com
 

Thanks Dominik,

Your comments have forced me to look at this in bit more detail(especially the design task). There is all sorts of disasters going on. Replica's missing, connection documents advising to replicate certain databases, databases without templates specified... it goes on and on.

I'll try and sort out before jumping in.

Regards,
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top