Search

What the Quote?

"Wow, that's depressing. But hey, that's death. And this is broccoli. [Belch]"

Tim Tripcony

"Did you know that when you cook chicken in red wine it turns purple?"

Laura Tripcony

"Where's the 'existing server'? Hold on, I don't know if 'redneck' has an I.P. address."

Steven Rodgers

« Quick tip: fixing a column that doesn't display what it ought | Main| upgrade to RYOML (roll your own markup language) »

script for rapid duplication of all replicas from one Domino server to another

Category domino
I spun up a new server at home that will serve three purposes: a media center hooked up to our HDTV, an onsite backup of most of what we've got on the NAS, and a backup Domino server. The server hosting this site (and various others) is quite the bride of Frankenstein and, while it's been significantly more reliable ever since migrating it from Windows to Linux, in the event that the hard drive ever goes monkey on me, I wanted the flexibility of being able to just flip a couple port forwarding settings on my router and immediately have all my hosted sites available again. Plus, it provides a few other conveniences in the meantime: running some resource-intensive Trigger Happy processes without affecting HTTP on this server, storing some databases that I can get to via passthru but can't simply be "stumbled upon" by the casual external observer, and so forth.

To that end, I wanted a quick way to ensure that all databases on the existing server have replicas on the new one. This can be manually done from the administrator client, of course, but I'm a programmer; I wanted a programmatic approach. Most scripts I've seen to do this scan the source server, check the target server for the existence of a replica of each, creating one if it doesn't find it. Handy, but takes forever, even for just a hobby server like mine. So I tweaked this approach ever so slightly: instead of creating a new replica, it creates an AdminP request instructing the source server to create a replica on the target server - just like the admin client does when you manually create new replicas in bulk. The end result was that, after about 30 seconds, AdminP was aware of all databases from Ophelia that weren't on Frodo (the new server is a 3"x8"x10" form factor, so I decided to give it a hobbit name instead of my usual Shakespearean naming convention), and once all requests had been processed, Frodo had a replica of each in the same relative filepath as Ophelia's replica of each... including a FTI if Ophelia's replica was indexed.

A couple usage caveats: having full admin access is handy for this, to ensure that you can access every database on the source server, and beware that some system databases that you might not want on the target server or don't want to be replicas (i.e. domlog) will be included if the target server doesn't already have a database at that location. I was going to post the database containing the agent for download, but the code is so minimal that I decided to just post the code. Sorry for all the pink... the syntax highlighter seems thrown by certain strings. Perhaps I'll dig into that at some point.

Sub Initialize
    Dim session As New NotesSession()
    Dim adminp As NotesAdministrationProcess
    Dim dbdir As NotesDbDirectory
    Dim db As NotesDatabase
    Dim path As String
    Dim currentServer As String
    Dim targetServer As String
    On Error Goto errorHandler
    
    Let currentServer = session.CreateName(session.CurrentDatabase.Server).canonical
    Let targetServer = session.CreateName(Inputbox("Target server (must be abbreviated or canonical):")).canonical
    If (Len(targetServer) = 0) Then
        Exit Sub
    End If
    Set dbdir = session.GetDbDirectory(currentServer)
    Set adminp = session.CreateAdministrationProcess(currentServer)
    Set db = dbdir.GetFirstDatabase(1246)
    While Not (db Is Nothing)
        Let path = Lcase(Replace(db.FilePath, "\", "/"))
        If (session.GetDatabase(targetServer, path, False) Is Nothing) Then
            Call db.Open("
","")
            Call adminp.CreateReplica(currentServer, path, targetServer, path, True, db.IsFTIndexed)    
        End If
resume4060:
        Set db = dbdir.GetNextDatabase()
    Wend
    Exit Sub
errorHandler:
    Select Case Err
    Case 4060:
        Resume resume4060
    Case Else
        Print "
Error in line " & Erl & ": " & Error
        Exit Sub
    End Select
    Exit Sub
End Sub

Comments

Gravatar Image1 - No, you're correct: it just generates a stub (if memory serves, it doesn't even copy over the database title... the initial title is the replica ID); for the contents to sync you still need a connection record. But the primary advantage remains: the heavy lifting is done in the background, with the servers' resources and permissions.

Gravatar Image2 - I thought creating new replicas via AdminP just created the replication stub and you have to replicate, either manually or scheduled a Connection document, to actually get the data to transfer.

Does it behave differently if you programmatically create the AdminP request, or am I wrong about how it works otherwise?

Gravatar Image3 - Thanks for clarifying that. Emoticon This is an awesome bit for the toolbox, thanks for sharing.

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)