A fast way to change NSF Replica IDs: Often a handy time-saver (and occasionally a life-saver)

Try to picture yourself in this situation: An end-user alerts you to the fact that they just did something very bad to a Lotus Notes database—and somehow accidentally deleted hundreds of essential documents. Naturally, this end-user doesn’t apologize for his stupidity, he just orders you to “fix it now.” Suppressing your natural urge to lay violent hands upon this person (who’s incidentally a “C-level” executive), your mind shifts gears to the problem at hand.

The only bit of good news is that he’s working on a local replica. So you could just destroy his computer with that fire axe hanging on the wall before the damaged databases replicates and spreads the problem, couldn’t you?—no, that’s too extreme. OK, but what if you just unplugged his LAN cable? Sadly, this ornery and unrepentant executive will have none of that, he’s expecting a “very important” email and wants you to “work your nerd magic” without interrupting his work.

But before you just resign yourself to accepting the database disaster that’s about to unfold, you think to yourself, “what if I changed the Replica ID of his database?” By doing so, you would be ‘unplugging’ the database from the normal replication cycle, thus preventing the ‘fire’ from spreading.

You’ve got to act quickly and scanEZ is the fastest way to change the Replica ID. (Note to people who do not have scanEZ licenses: This feature is available in the free Lite version of the tool).

You just have to do the following:

1) Open the database in scanEZ…

… and the Database Information panel will open immediately.

2) Now, if you need to, just copy the current ReplicaID to the clipboard and paste it somewhere for safekeeping.

3) Next, click the Create New button to generate a new Replica ID (Alternately, you could manually type in a new replicaID)

4) Click Save.

That’s it. The link between this database and any other replicas is now broken. So now you can fix the database issue at your leisure without worrying about the problem spreading via replication. (Note: this particular issue could be fixed using scanEZ. You’d just trash the deletion stubs of the documents that the end-user accidentally deleted; the “deleted” documents would then be regenerated from another replica during the the next replication).

The situation above is admittedly not an everyday sort of problem. And even if it were a common occurrence, the “change replica ID” solution would only actually help you in cases where the replication interval was long enough for you to act (that said, the story above was loosely based on a something that actually happened to someone here at Ytria). Nevertheless, changing the replica ID can also be quite useful for dealing with less dramatic Notes/Domino challenges.

If you simply copy an NSF file in Windows, it will be a bit-for-bit copy of the database (including the Replica ID). This is great. But if this database copy were at any time accidentally placed in a directory where it would seen by Domino, it might inadvertently be included in the replication process.

So using the scanEZ method to change the replica ID and break the copy database’s link with other replicas is a very useful tool for NSF backups. If the backup ever needs to be changed back into a replica, you could use scanEZ to paste in the valid Replica ID.

Why not just use the File>Application>New Copy option in Lotus Notes? Well, that’s a perfectly fine method for creating copies of database in most instances, however, unlike a bit-for-bit copy in Windows, these ‘copies’ will have all their Added and Modified in this file dates changed. So whenever you want to maintain the integrity of dates, it’s best to create a new copy in Windows and change the replica ID in scanEZ.

Imagine you need to do a major overhaul on an important database, and this work will take you more than an hour to complete. And this database has replicas that can’t be taken off-line. If your changes are constantly replicating, it can be jarring for end-users to see the database they’re accessing suddenly turn into a construction zone.

In these types of situations, it’s worth taking a moment to change the replica ID with scanEZ. By doing so, you can temporarily isolate your NSF work site and prevent half-finished changes from going into production.

Once you’ve finished making the changes to the database and tested those changes to your satisfaction, it’s simple to restore the replication link. Just open one of the other replicas in scanEZ and copy its replica ID to the clipboard. Next, open the database that you worked on in scanEZ and paste the contents of the clipboard to the Replica ID field and click Save. That’s it.

Have you (or has the new guy or gal) ever accidentally created a new copy of a database when you intended to create a replica? If so, it’s not the end of the world: you can just paste the valid replica ID to this copy to transform it into a replica. That’s all there is to it and this is often considerably faster than building a new replica from scratch.

Bill Buchan’s and Paul Mooney’s 2006 Lotusphere “Worst Practices” presentation offered another great example of where you can really get snake-bitten by Replica IDs. Here’s a quick paraphrase: There was an organization where some of the end-users’ Notes data directories were placed in a network Home drive to facilitate roaming. However, since new users’ data directories were created from an image, their personal address books (PABs) all had the same replica IDs. And as a result, replication between these PABs started to occur and the end-users ended up sharing contacts. You can fix this problem by simply giving new Replica IDs to the personal address books. To read the authors original description, see pages 8 and 9 of the PDF document linked above.

Hey reader: Do you have any tips related to changing Replica IDs? If so, it would be great if you could share them in the comments.

UPDATE In the time since this tip was published Ytria has released a new product called ‘databaseEZ‘. This tool lets you select any number of databases on a server and generate new Replica IDs for them in a single operation. It also allow you to quickly edit any individual database’s Replica ID via a right click menu option.