A senhasegura update with an arbiter

[Rebeca_VP (Rebeca Vitoretti Parmigiani)]

Prerequisites:

• Access to the senhasegura arbiter.
• Snapshot (it is necessary to perform a snapshot only for thesenhasegura instances, it is not necessary to perform it for the arbiter).

---

To update asenhasegura environment with two nodes and one arbitrator.

IMPORTANT: Any and all maintenance that will restart (or shut down) the instance, stop (or restart) the Database service in asenhasegura environment that has an arbitrator, must first remove the arbitrator from the cluster

Source:
https://docs.senhasegura.io/docs/en/maintenance-with-senhasegura-and-arbitrator

1. Before starting, validate that all nodes are in the cluster.

1.1

orbit cluster status

1.2

orbit elasticsearch status

2. Remove the arbiter from the cluster.

As mentioned above, it is necessary to remove the arbiter from the cluster before any servicing onsenhasegura that involves a reboot or poweroff of the instance, in addition to a possible restart of the database service.

2.1 Access the Docker Host where the arbiter is configured.

2.2 Locate the folder where the Docker configuration files were inserted. By default in our documentation we recommend /opt , if you don’t find it, it means that the deployment was done in another directory. Use binaries like history , find , grep searching for docker , manifests , docker-compose or arbiter .

2.3 Removing the cluster arbitrator with docker-compose .

After accessing the arbiter configuration directory (in the example it is /opt/manifests/docker-compose ), access the folder that has the file docker-compose.yml and execute docker-compose down .

If the environment does not have docker-compose

2.3.1 Removing the arbiter from the SEM cluster docker-compose .

elasticsearch Identify the e container ID garb with the command docker ps .

After identifying them, run docker stop ID to manually stop the service.

3. Updatesenhasegura normally. Remember to take snapshots!

Below are support links in the update.

Attention! This procedure may take time. The senhasegura services will be restarted several times. Consider a downtime window of more than 1 hour depending on the client’s internet bandwidth, MT4 link quality of the mirror, and amount of records in the client’s database! Before proceeding with the upgrade, it is very important to take a snapshot of the senhasegura instance. To do it, shut down the instance that will be updated with the ‘orbit shutdown’ command and then take the ‘snapshot’ from…

https://docs.senhasegura.io/docs/installation-update-senhasegura

4. After finishing thesenhasegura update, restarting the instances and testing the functioning of the environment, it is time to generate a new image of the arbiter according to the new version .

---

ALWAYS GENERATE A NEW IMAGE OF THE ARBITER AFTER UPDATE PASSWORD.

---

To generate a new image:

orbit cluster arbiter create-config

5. Access the arbiter and move the configuration folder prior to the update to avoid generating conflicts.

If the .tar.gz file from the old manifests still exists in the folder, delete it.

Ensure that any folder or configuration referencing the arbiter has been properly moved or deleted before upgrading.

6. Send the arbiter files to Docker Host and carry out a new deployment process.

For transfer:

https://docs.senhasegura.io/docs/arbitrator-senhasegura-cluster-settings#transfer-files-to-docker-host

For configuration:

https://docs.senhasegura.io/v3-29/docs/arbitrator-docker-settings

[Red_213 (Red)]

Hello,

I have couple of questions regarding Senhasegura cluster.

1. When you create cluster with two instances and arbitrator, you have to choose Primary node in cluster right? I mean in official documentation no word about choosing primary node.
   senhasegura cluster settings
2. When you create cluster it becomes active-active right?
3. When you have two instances it is necessary to have arbitrator to avoid split-brain right?

[Jade_Ariel (Jade Ariel Galindo Cunha)]

Hello Red,

1. On the configuration for a cluster with the arbitrator or not, the first node on the sequence of commands will be the primary; in the example sent, the primary instance is 192.168.0.8.
2. When you create a cluster, the configuration of activeXactive or activexpassive is not applied, you configure this by leaveing the second instance activated or not on ‘Orbit Config. Manager → Settings → Application → Enable Application’.
3. The split-brain scenario happens when it is necessary to protect the database. Having an arbitrator will help reduce the chances of this happening, and if one of the nodes gets down, it can come back normally. You can see more information about this here: High Availability and Disaster Recovery

Best regards.