{"id":1890,"date":"2016-07-11T05:00:19","date_gmt":"2016-07-11T05:00:19","guid":{"rendered":"http:\/\/update.prominic.net\/?p=1890"},"modified":"2023-03-28T18:34:53","modified_gmt":"2023-03-28T18:34:53","slug":"replicating-notes-databases","status":"publish","type":"post","link":"https:\/\/wordpress.prominic.net\/replicating-notes-databases\/","title":{"rendered":"Using AdminP To Migrate Databases And Create New Replicas"},"content":{"rendered":"
It\u2019s an age-old problem: you have brought in a shiny new server host that is going to join your Domino environment and eventually replace your wheezing old server whose fans blow out dust that stinks of death<\/em>. But that old server has accumulated tens or hundreds of databases that need to be moved over to the new server before it can ride off into the sunset. The choices have often been having downtime and client ire for a filesystem-level copy or manually replicating databases over and spending countless hours on the dull task. Fortunately, Domino has the AdminP replica creation<\/strong> tool, which can handle all this for you and, if you know what to look for, is quick and easy to configure.\u00a0<\/strong><\/p>\n\n The very first thing you\u2019ll want to check is that the servers can connect to each other, have access permissions, and have replication scheduled between the two of them.<\/p>\n To verify the servers can connect to each other, the easiest thing is to run a trace from the server console. From either inside the Administrator (under Server -> Status -> Server Console<\/em><\/strong>) or directly from the console on the server itself, run a \u201ctrace <<REMOTESERVER\/ORG>>\u201d<\/strong>. If you are successful, the last lines of the trace should something like this:<\/p>\n Connected to server REMOTESERVER\/ORG<\/strong><\/p>\n Attempting Authenticated Connection<\/strong><\/p>\n Compression is Enabled<\/strong><\/p>\n Encryption is Enabled<\/strong><\/p>\n If this has failed, you may be able to fix it on the connection document, which is the next item we want to look at. From the Domino Administrator<\/strong> or the names.nsf<\/strong> you can find these under Configuration -> Server -> Connections<\/em><\/strong>. You will most likely see a section for each server in your domain, and you can hit + (shift-=) in order to expand the listing and see all the connections. You can either create new connections or edit existing documents, but when you\u2019re finished you want to have a connection from your old server to your new server and vice-versa.<\/p>\n In each of these connection documents, there are just a few items on each tab you\u2019ll want to set\/verify:<\/p>\n Lastly, you\u2019ll want to verify permissions in the server documents. In the server document (Configuration -> Server -> Server Documents<\/em><\/strong>) for each server, the opposite server can either be explicitly entered or part of a group that, in the lower-left Server Access<\/strong> section, is listed in the Access Server<\/em>, Create Databases & Templates<\/em><\/strong>, and Create New Replicas<\/em><\/strong> fields. If this is not the case, the most reliable method is to add the remote server explicitly, such that Server B\/Org<\/strong> is listed in these three fields on the server doc for Server A and vice-versa, though listing LocalDomainServers<\/strong> will generally work, as well. And don\u2019t forget to replicate the names.<\/strong>nsf changes to the other server!<\/p>\n At the end of this section, the trace command from above should work properly, and all the replica creation permissions should be ready.<\/p>\n Part 2: Check database ACLs<\/strong><\/p><\/blockquote>\n Next, you will need to prepare the databases for the replication process. There are three key permissions that will be needed for every database you will migrate:<\/p>\n One additional warning: for databases whose administration server (under the Advanced<\/strong> tab of the ACL) is not specified, is in a different domain, or is not a reachable host, LocalDomainServers<\/strong> or similar local groups may NOT be sufficient to meet this demand. If you are concerned about this possibility you can either explicitly add both servers to the ACL or you can test on a smaller set of databases and check whether AdminP throws any errors (covered in Part 4).<\/p>\n Part 3: Generate Create Replica requests<\/strong><\/p><\/blockquote>\n From the Administrator<\/strong> client, open the current server and go to the Files<\/strong> tab. Depending on what your folder structure is like, you may wish to view the databases in All view (immediately to the left of the Tools<\/strong> menu). If you are looking to make the new server a 100% replacement for the existing one, you can hit the All view and then ctrl-A<\/strong> to select all in the files view. Since AdminP will NOT overwrite existing system databases, if the new server is a fresh install this will replicate over all non-default databases without forcing you to manually un-select default system DBs.<\/p>\n When you\u2019ve selected all of the databases you wish to migrate over, open the twisty for the Tools<\/strong> menu in the upper-right, then expand Database<\/strong> and click Create Replica(s)<\/strong>. The remote server may already be listed in the field for Create Replicas<\/strong> on these servers, but if not you can choose Other\u2026<\/strong> to manually specify it.<\/p>\n NOTE:<\/strong> If you manually enter the server you will need to specify the full Domino server name, Remote server\/Org<\/strong>.\u00a0Once this is created you should see the Destination database and server box on the right populate with your remote server(s) and databases, then when you hit OK<\/strong> you\u2019ll see these process through in the status bar at the bottom of your administrator.<\/p>\n Part 4: AdminP, Engage!<\/strong><\/p><\/blockquote>\n At this point, the databases should all be prepared to be replicated from your origin server to the destination server, and all that is left should be to run the actual AdminP requests themselves. While these should run within a short time on any server with AdminP enabled, it is quicker to launch this process manually. Open the server console on the origin server and issue \u201ctell AdminP process all.<\/strong>\u201d<\/p>\n You will then see the server reply with one or more messages per database that will each fall into three categories:<\/p>\n As long as not all databases failed, the next step is to replicate the admin4.nsf<\/strong> to the destination server; issue a \u201creplicate <<REMOTESERVER\/ORG>> admin4<\/strong>\u201d on the server console. You may see some databases begin to initiate already, clearly a good sign, though if you do not it is not yet an indicator that the migration process failed.<\/p>\n Switch to the console for the destination server and then run another \u201ctell AdminP process all<\/strong>\u201d. You will likely see few messages or some database initializations; even if there is no console feedback that may be okay. Then issue a \u201cpull <<REMOTESERVER\/ORG<\/strong>\u201d (of course indicating the origin server, here). You should start seeing replicas being created and populating immediately, and can track the progress either through the files view (NOTE:<\/strong> this is not updated in real-time and you will have to refresh or use F9<\/strong> in order to see the updated files and file sizes) or by issuing a \u201cshow tasks<\/strong>\u201d on the server console to see what replication processes are running.<\/p>\n Part 5: Verify Results<\/strong><\/p><\/blockquote>\n While the most obvious indicator of success or failure will be seeing the databases actually created by the end of the previous steps, there are two great ways to double-check the full results or correct any problems.<\/p>\n First, open the admin4.nsf<\/strong> on the origin server, then select Errors by Server<\/strong> from the left-hand view menu. Expand the sections for both your origin and destination servers and the most likely error categories will be \u201cAccelerated Create Replica<\/strong>\u201d or \u201cCheck Access for New Replica Creation<\/strong>\u201d. In the former category, you can expect the majority of the errors to be related to files that already exist on the remote server, most frequently system databases. In the C<\/strong>heck Access<\/strong> category you are likely to find any files that failed due to any lapses in Part 1, above.<\/p>\n Opening each document, you can see the error field, which generally is populated with good, specific information on why the request failed, whether the source or destination server didn\u2019t have access, whether the requestor didn\u2019t, or whether the source server didn\u2019t have create replica privileges or a connection to the destination. In any of these cases, you should be able to address the specific issue by fixing the ACL, connection, or server permissions per the steps in Part 1, and then once that is done just return to the admin4.<\/strong>nsf, select the documents to be re-run from the Errors<\/strong> view, and then use the Reprocess Selected Requests<\/strong> button from the action bar. These requests will be re-queued anew and you can return to Part 4 to monitor their activity.<\/p>\n Second, once you have finished checking all of the admin4 errors or failures, running a decommission server analysis is a great way to verify your files did make it across successfully. Open the Server<\/strong> tab of Administrator, then the Analysis<\/strong> sub-tab. From the right-side Tools<\/strong> menu, select Analyze -> Decommission Server<\/em><\/strong>. Specify Source Server<\/strong> and Target Server<\/strong> as the source and destination servers (NOTE:<\/strong> if your server names are too long to be entered manually you will have to use the drop-down menu to populate these fields. If a server is not listed here opening a database on that server will typically fix this.). Returning the results to a local database is fine, and overwriting the database for each server decommission pair and then appending further reports helps keep organization simple.<\/p>\n Once the decommission analysis report completes, we will want to open the Databases<\/strong> section and look over the Databases \u2013 No Matching Replica<\/strong><\/em> and Databases \u2013 Name Conflict<\/strong><\/em> reports. The former will list any databases where a matching replica is not found, most likely due to not having been selected for migration, an AdminP migration failure, or an existing file with the same name. The name conflict report will indicate all databases that have the same name but different replica ID\u2014these will mostly be system databases that should exist as separate replicas on each server, but you\u2019ll want to be certain the names.nsf<\/strong> or admin4.nsf<\/strong> aren\u2019t listed.<\/p>\n Going through these five sections, you should be able to get replication stubs of databases created on a remote server in short order. While the time savings are immediate if you have a large number of databases to move, admins familiar with the steps will generally find them faster than manually creating replication stubs for even as few as 5-10 databases, particularly as parts 1 and 2, generally the most time-consuming, need to be reviewed even for either method.<\/p>\n\n
\n
\n