This is something I may have done once and forgotten. Or maybe I just got lucky before. I have a very large database in a clustered environment that is bloated, in danger of going corrupt (other replicas are much smaller on other servers and another one that got this big went corrupt). It has resisted efforts to clean up (ncompact, nfixup etx with server down) and is always busy.
I need to “sneak in” a new replica and do a swap.
The general plan is to create a new replica in a different folder path and then shut down and swap the files at a non-peak time.
This tends to not work, because other servers and clients that replicate with this db sooner or later hook up with the new, small replica and start replicating with it, bogging them down, since it’s not finished yet and it has hundreds of thousands of documents not yet replicated. The other server that I originally created the new replica request from has no precedence in the process, they all barge in to replicate and it becomes just one of the crowd.
Is there a foolproof way to sneak a new replica into place using replication properties, ACLs or something?
Do not do any copying at the filesystem level, keep it all in Notes.
Now what you want to do is quite a simple procedure in a clustered environment. First you want to delete the corrupt database do this in the cluster by marking it “Pending for delete” This was the server will handle restricting access to users and once all active users have closed out of the db it’s changes will be replicated to the other cluster replicas and then the database deleted. Then you just create a new replica of the database in it’s place. Very simple, another way to do it is to mark the db out of service so no new users can access the db and then once all active users are disconnected you can push changes, delete and recreate the replica all manually.
We had problems a few years ago due to this method. It was suppose to be related to an old version of Lotus Notes. The technote is from 1997-12-15.
For what I can say, the problem is still there in 6.5.
technote 156522
Duplicates of Databases Created at the Operating System Level Do Not Replicate
Problem:
You create a duplicate of a replica database at the operating system level and the database does not replicate with the original database.
Solution:
This issue has been reported to Lotus Quality Engineering; however, it was determined not to be a software problem.
Replicas should be created using Notes by selecting File, Replication, New Replica because the replication setting “Only Replicate Incoming Documents Saved or Modified After” is cleared when a new replica is created. If a replica must be created using the operating system, you will need to manually clear the “Only Replicate Incoming…” setting, as well as the Replication History.
Thank you all. Unfortunately I want something more particular - the database is not corrupt currently, just nearing the brink, and I want an instant (like in the few minutes that it takes to stop and start the server) swap to a fresh replica. An OS file copy pulls all the corrupt internal structures with it and makes a file of the same bloated size, so a new replica has to be built.
I expect the build to take about 10 hours. To delete and then replace the database would mean that it would be gone for a moment, then have incomplete data for 10 hours.
My only real question is how to keep other clients and servers off the newly building database. I am afraid that if I make restrictive ACL changes to the new file while it’s building they might propogate to other replicas.
Charles, just mark the new replica “Out of Service” in the cluster. that way users can not access it but the server can. There is help topic on doing this in the Admin help.
Subject: That doesn’t work for remote users with local replicas tho…
Just a note ontop of this suggestion.
We are attempting to accomplish something similar, and running into roadblocks everywhere.
We want to restrict replication access to a single server in our cluster. However, flagging a database as “out of service” does not restrict clients from replicating that database.
This is especially important when trying to “rebuild” a replica on a given server (as I believe was posted earlier in this thread), since you don’t want clients trying to replicate with a database which is only partially rebuilt (ours is over 10GB, and we are still struggling to find the answer).
You can also create a copy of the file through Windows. The replica ID will be the same. When I have done this before I have experienced it works fine after a consistency check of the new file is perfomed. I believe that you will have to make the replica outside of the data folder though because replication does not follow folder structure, it just looks at replica ID and you don’t want 2 replicas of the same database anywhere in the data folder or its subfolders.