B: Migrating Realm Servers to FTL Servers

To migrate from Release 5.4 realm servers to Release 6.x FTL servers without interrupting service to clients, complete this task.

1. Backup the realm server database.
   You can use the tibrealmadmin utility from Release 5.4.

Migrate the primary realm server and its backup server. (Later, you will repeat these steps for satellites and disaster recovery sites.)

2. Designate three host computers to run FTL servers.
   Re-use the two hosts that already run the primary realm server and its backup (5.4). The third must a be new host that you designate for this purpose.
3. Install Release 6.x on all three hosts.
4. Prepare a single configuration file for all three of the new FTL servers (6.x).
   In the globals section of this file, specify the three core server hosts.
   In the servers section of this file, configure only the realm services. Omit other services until later. For example:

   globals:
   
       core.servers:
           ftl1: host1:8080  # 5.x default client port, replaces primary
           ftl2: host2:5238  # 5.x non-default client port, replaces backup
           ftl3: host3:8585  # 6.4 default port
   
   servers:
   
       ftl1:
           - realm:
               data: /myhome/ftlserver/data
   
       ftl2:
           - realm:
               ftl: host2:5331
               data: /myhome/ftlserver/data
   
       ftl3:
           - realm:
               data: /myhome/ftlserver/data
   

   Incorporate the relevant realm server command line arguments into the new configuration file.
   Ensure that the new FTL servers use the same data directory as the old realm server that they replace.
   Note: If 5.x clients connected to the 5.x realm server at default ports, then you do not need to configure ports for backward compatibility.

   In contrast, if the 5.x realm server specified non-default values for --http or --ftl, then specify the corresponding backward compatibility URLs for the realm services (6.x) that replace the primary and backup realm servers (5.4). That is, configure core server port with the value of the 5.x HTTP port, and configure the realm service FTL address with the value of the 5.x FTL port. Clients using the FTL 5.4 library connect to the replacement realm services at these old addresses. When all the clients have migrated to the FTL 6.x library, you can delete the backward compatibility FTL addresses from the configuration file.

5. Stop the backup realm server (5.4).
   Leave the primary (or satellite) realm server (5.4) running.
6. Start two FTL servers (6.x) on separate host computers.
   1. Start one FTL server on the former backup host.
      The data directory for this FTL server must be the existing data directory from the former backup host (5.4).
      The FTL server (6.x) loads the existing realm definition from that data directory.
   2. Start the second FTL server on the new third host.
      The data directory for this FTL server must be empty.
      The two FTL servers (6.x) automatically force a quorum, even though an odd number of servers is not present.

      They synchronize the realm definition data. Both data directories now contain an identical realm definition.

   3. Verify quorum status in the realm status panel of the FTL server GUI.
7. Stop the old primary realm server (5.4).
   Clients of that realm server failover to the new FTL servers (6.x).
8. Start a third FTL server (6.x) on the former primary host computer.
   The data directory for this FTL server must be empty.
   Wait for it to join the quorum and synchronize realm definition data.
   Migration is complete for this quorum.

At each satellite location, migrate the satellite realm server and its backup server.

9. Prepare a single configuration file for three FTL servers at each satellite location.
   Configure the value of the satelliteof parameter as a pipe-separated list of FTL server URLs at the primary site.
10. For each satellite network, repeat the preceding steps for migrating the primary.

Migrate the disaster recovery realm server and its backup server.

11. Prepare a single configuration file for three FTL servers at the disaster recovery site.
    Configure the value of the drfor parameter as a pipe-separated list of FTL server URLs at the primary site.
12. Repeat the preceding steps for migrating the primary.
13. Optional. Prepare a parallel configuration file that reconfigures the disaster recovery FTL servers as primary servers.
    Use this parallel file only after an actual disaster occurs. Preparing it in advance can save time during recovery.

    Copy the existing configuration file, but omit the drfor parameter.