Skip to main content

Adding a node steps in detail

Caution

Before starting this procedure, ensure that you have created the new server according to the requirements described in Preparation for setting up replication environment.

Verify that there are no database-intensive scheduled tasks that can be triggered on any of the database nodes of the instance if database resynchronization will have to run:

  1. On the web-based interface, click Manage the system > Maintenance > Scheduled jobs > PSUPDATE > Disable.

    Repeat that for any other jobs like autores if it was scheduled.

    Disable rotatelog to avoid the log rotation to remove the temporary iddb.cfg before the operation ends and to be able to find the logs of the operation in the same file.

  2. On each application node’s Windows Scheduler > Library, right-click and disable any "HID*" task.

  3. Disable any other database-intensive API automation that is scheduled elsewhere.

Remember to re-enable these tasks after the database resynchronization completes.

Depending on your chosen replication network topology, there are different steps for adding an application node.

Direct replication

A database node is an application node connected to its own database, not shared by any other node.

To add a new database node (application node connected to its own database, not shared yet by any other application node) to Bravura Security Fabric replication environment:

  1. Log onto your primary node as a product administrator

    Warning

    Adding a node from a replicated node will result in the new node overwriting existing nodes and becoming the primary node.

  2. Click Manage the system > Maintenance > Database replication.

  3. Before the very first node can be added, you must enable replication on the primary node. To do this, select the default node and set Mode to "Enabled" and click Update.

  4. To add the next node click Add new...

  5. Type the Address of a replicating instance’s server and the corresponding Database Service (iddb) Port number (the default port number is 5555).

  6. Click Continue.

  7. Type a node Description.

  8. Set the Mode to:

    • "Enabled" if you want this node to send and receive information to and from other replications nodes.

    • "Suspended" if you want to temporarily stop communication with other nodes.

      If the replication is suspended on a node, then changes made on other replication nodes will not be propagated to this node, but will be queued.

    • "Disabled" if you want to disable communication with other replication nodes.

  9. Set the received and/or send Queue size limit, if required.

    When database replication is unavailable, replication data is queued until the queue file has reached its size limit, or the node comes back online. You can modify:

    • Receive queue configuration for this node

    • Send queue configuration for all nodes replicating to this node

    You can set the queue limit to a fixed size, using the following settings:

    • Minimum queue size - default is 100MB

    • Maximum queue size - for fixed size limit

    • Queue usage warning threshold (%): - default is 60%

    You can set the queue limit to a percentage of disk, using the following parameters:

    • Minimum queue size - default is 100MB

    • Maximum usage before queue stops growing (%): - default is 90%

    • Disk usage warning threshold (%): - default is 60%

  10. Click Add.

  11. Propagate replication changes (see below).

Propagate replication changes

Once you have modified the configuration of a node in a replication environment, you must propagate the node configuration to all connected servers. The status for the nodes will change to "Reload required" on the Select a replication node page.

To do this:

  1. Ensure all nodes can successfully communicate with each other. When propagating changes, the system checks that all nodes can connect, and if any connection issues are detected, propagation will fail.

  2. If adding a new database node, verify there is enough space available on:

    • The source application node (the one from whose web-based interface the propagation is triggered)

    • The target nodes (the ones where the propagation goes)

    • Their respective backend databases. See Resynchronizing databases for details.

  3. On the Database replication page, click:

    • Propagate and reload replication configuration on all servers (without resynchronizing nodes)

      This is recommended when wanting to replicate changes without dropping data on the newly added node and replacing it with data from the current node

      Or

    • Propagate and reload replication configuration on all servers to propagate changes

      When adding a new node this propagate changes and replicates the entire database to the new node.

  4. Wait while the Database Services reload the changes and possibly builds queue files.

    Click Refresh to check progress, as indicated in the status column.

    If a node is in "Reload in progress" status, or is running auto discovery, you cannot make any changes to the replication nodes until the reload is complete.

    The Propagate and reload replication configuration on all servers option only appears if a change in the configuration has occurred.

Configuration notes

  • When you configure database replication, Bravura Security Fabric creates a temporary iddb.cfg file in the log directory. The files record the configuration information for backup. The information is rotated with the log files by the Logging Service (idmlogsvc).

  • If a server detects that one of the nodes has a different replication configuration, then a message opens to notify you of the need to propagate this replication configuration over to the other server.

  • If you change which server is the primary server, you must update which server’s scheduler will run psupdate.

  • Do not propagate changes while auto discovery (psupdate) is running.

  • When propagation changes include queue sizing, the queues are adjusted dynamically. Queues files that still include data will remain until the data is either sent or committed, regardless of queue settings. When a new queue file is needed or a queue file is no longer needed, then the queue sizings are considered.

See also

For information about recovering from network failures, see Recovery.

Warning

Using the automated data resync buttons (Resynchronizing databases) can lead to extended outage on the source and destination nodes, and in some cases, loss of data, configuration and application functionality. Do not trigger automated resynchronization in production instances unless you cannot use the manual method and you already scheduled an outage.

Shared schema

When adding an application node to an existing database, all that is required is to install the node while selecting the existing database of a previously installed application node, as described in Installing with a shared schema . This is the simplest way to create a shared schema node.

If a database has to be retired but its application nodes are still needed to provide web-based interface resources for users, this can also be done after node installation:

  1. Have a fully installed database node (application node with its own database)

  2. On the new application node, use the iddbadm utility to change the database connection details and point to the database used by the other node.

  3. Delete the database used when creating the new application node. In this case it is not used anymore.

    If you allow setup to create the new database during installation, it will do so with the same name as the instance, and you cannot use the same backend database instance to install two databases with the same name.

Best practice

In a shared-schema replication environment it is recommended that you propagate changes to the replication environment without initiating a full database resynchronization. On the Database Replication page, the option to Propagate and reload replication configuration on all servers (without resynchronizing nodes) is available for this purpose.

Hybrid schema

There are two ways to add nodes to a hybrid schema:

  • Adding a database node with application nodes

  • Adding one application node to each of the existing database nodes

Adding a database node with application nodes

To add failover, further geographical support, nodes in a new data center and/or complete 100% uptime requirements, add a database node with the same number of application nodes as the other existing database nodes; that means going from this topology:

DB/Schema A

Replication

DB/Schema B

Node A1

<– –>

Node B1

Node A2

<– –>

Node B2

… to this one:

DB/Schema A

Replication

DB/Schema B

Replication

DB/Schema C

Node A1

<– –>

Node B1

<– –>

Node C1

Node A2

<– –>

Node B2

<– –>

Node C2

To do this:

  1. Consider A1 is the primary node of the instance

  2. Create node C1 as a full database node pointing to Database C and using the instance’s idmsetup.inf

  3. Create node C2 as a shared schema node pointing to Database C

  4. From A1’s web-based interface click Manage the system > Maintenance > Database replication, add C1’s server and port and propagate changes without replication.

  5. From A2’s web-based interface click Manage the system > Maintenance > Database replication, add C2’s server and port and propagate changes without replication.

Adding one application node to each of the existing database nodes

To add web-based interface and/or automation resources, add a new application node to each of the existing database nodes; that means going from this topology:

DB/Schema A

Replication

DB/Schema B

Node A1

<– –>

Node B1

Node A2

<– –>

Node B2

… to this one:

DB/Schema A

Replication

DB/Schema B

Node A1

<– –>

Node B1

Node A2

<– –>

Node B2

Node A3

<– –>

Node B3

To do this:

  1. Consider A1 is the primary node of the instance

  2. Create node A3 as a shared schema node pointing to Database A.

  3. Create node B3 as a shared schema node pointing to Database B.

  4. From A3’s web-based interface click Manage the system > Maintenance > Database replication, add B3’s server and port and propagate changes without replication.

In this section: