From the Linux Wiki

Setting up replication

Master server

my.cnf on the master server:

[mysqld]# Server ID. It must be unique on each link of servers (both masters and slaves). # Is a number in the range 1 to 4294967295 (2 ^32 -1 ) server-id = 1 # Path to binary logs where all changes in the master server database are saved. There should be enough space for these logs log-bin = /var/lib/mysql/mysql-bin # How many days to keep binary logs on the master. In some way, this also determines how much the slave can lag behind the master # expire_logs_days = 10 # Size of the binlog file (each individual file) # max_binlog_size = 1024M # Enable compression of logs sent to the Slave slave_compressed_protocol = 1 # Name of the database for which to do replication. If you need to replicate several databases, repeat the option with the desired database name replicate-do-db = testdb # In addition to this option, there are more options "reverse choice"- to exclude selection of databases # replicate-ignore-db= database_name # as well as options for replicating individual tables (similarly - select one / several ; exclude one / several, as well as the definition of names through wildcards)# This option is needed in case this master server is a slave to another - so that the slave for this master (sub-slave of the main master) also receives updates # May be useful when replicating a master-master with one slave # log-slave -updates

We give the rights to the slave server to replicate from this. To do this, in the mysql console we give the command:

mysql> GRANT replication slave ON * .* TO "repluser" @"replhost" IDENTIFIED BY "replpass" ;

repluser- username to connect. The user is created at the time the command is executed.
replhost- IP address or host domain of the slave server that will connect to this master and import changes from it.
replpass- connection password

Restriction on the base for replication in grant replication does not seem to work - i.e., we allow everything, and in the config we specify only the base / bases that are needed

We restart the server, after which you can run the command in the console

mysql> SHOW MASTER STATUS ;

which will show the binary log file the master is currently working with and the current position in the log, as well as the base(s) being replicated.

Slave server

Add the necessary options in the config my.cnf on the slave server:

[mysqld]# Server ID for this server bundle - see description above server-id = 2 # Relay logs - logs downloaded from the master server # Specify the path for these logs ; there should be enough space to store them.#relay-log= /var/lib/mysql/mysql-relay-bin#relay-log-index= /var/lib/mysql/mysql-relay-bin.index# Name of the database to be replicated replicate-do-db = testdb # Enable compression of logs sent to the Slave slave_compressed_protocol = 1

Restart the server to apply the changes

Start replication

On the master, we lock the tables for writing to get a completely correct dump:

mysql> FLUSH TABLES WITH READ LOCK ; mysql> SET GLOBAL read_only = ON ;

We merge a dump from the server. In some places they usually write about the fact that it is necessary to look at the position and name of the log on the master - this is not necessary and is solved by the key --master-data for mysqldump, which will write the necessary information to the dump itself:

mysqldump --master-data -hmasterhost -umasteruser -pmasterpass masterdbname > dump.sql

After that, we start the wizard to work:

mysql> SET GLOBAL read_only = OFF;

(although the thought arises - is it really necessary to lock the database when dumping? As soon as the dump with --master-data began to be made, the log name and position are thrown into it, and the tables are automatically locked for writing - i.e. everything is the same, only in automatic mode)

mysql -hslavehost -uslaveuser -pslavepass slavedbname< dump.sql

IN this case slavedbname = masterdbname, although if desired, you can make the database replicate under a different name.

Specify the address of the master server to the slave:

mysql> CHANGE MASTER TO MASTER_HOST = "masterip" , MASTER_USER = "repluser" , MASTER_PASSWORD = "replpass" ;

Where masterip- The IP address or domain of the master server, and the remaining options are those that were specified above when setting up the master. The name of the log file and the position are taken from the dump, but if desired, they can be manually specified via the options MASTER_LOG_FILE = "log_name", MASTER_LOG_POS = position

After this command, information about the master is saved in a file master.info in the database directory mysql data-server. If desired, you can specify these options in the slave server config:

master-host=masterip master-user=repluser master-password=replpass master-port=3306

After that, we start the slave server through the mysql console:

mysql> START SLAVE;

Now you can check the status of the slave server with the command

mysql> SHOW SLAVE STATUS ;

From interesting information there may be fields:

Slave_IO_State: Waiting FOR master TO send event, Slave_IO_Running: Yes And Slave_SQL_Running: Yes- everything works well:)
Seconds_Behind_Master- how far the slave is behind the master. In normal mode, it should be 0, but in real lag, it can also be 0 if a lot of changes are made on the master, and the channel between the master and the slave is narrow and the latter does not have time to download binlogs from the master. In this case, "0" is correct, but only for what has managed to download from the logs.

And other current information like no errors, current position and name of the server log, slave log, etc.

Miscellaneous

There are 2 options for mysqldump to write the log name and position in the dump file: --master-data And --dump-slave. The second is not everywhere:

[email protected]:~# mysqldump --help | grep "dump-slave" [email protected]:~# mysqldump --version mysqldump Ver 10.13 Distrib 5.1.61, for portbld-freebsd8.2 (amd64)

Dump-slave[=value] This option is similar to --master-data except that it is used to dump a replication slave server to produce a dump file that can be used to set up another server as a slave that has the same master as the dumped server. It causes the dump output to include a CHANGE MASTER TO statement that indicates the binary log coordinates (file name and position) of the dumped slave"s master (rather than the coordinates of the dumped server, as is done by the --master- data option).These are the master server coordinates from which the slave should start replicating.This option was added in MySQL 5.5.3.

Accordingly, one option is for cloning a slave, the second is for creating a subslave. In other words, dump-slave allows you to create (using slave1) another slave1 in the master-slave1-slave2 chain (the position in the log and the log file relative to the master logs will be written to the dump), master-data allows you to create slave2 - the position / log relative to slave1's binlogs.

Replication errors

When replication is running, errors may occur - for any reason, for example, manually entering data on a slave server.

Solution options.

Setting up MySQL replication without stopping the wizard.

1. Master server setup:

We look where the config should lie.

# ps aux | grep my.cnf

mysql 51189 0.0 0.0 17064 1912 - Is 6:35PM 0:00.05 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file= /var/db/mysql/my.cnf--user=mysql --datadir=/var/db/mysql

If the file is missing, you can copy it from the example.

# cp /usr/local/share/mysql/my-small.cnf /var/db/mysql/my.cnf

Or create an empty one.

# touch /var/db/mysql/my.cnf

To the created config in the section we write.

#Unique server ID. The master must be below the replica and not duplicated

server - id = 1

#log format

binlog - format = mixed

#Path where the binlog will be located (By default, the size of one log is 1g)

#Binlog storage time

expire_logs_days = 30

replicate-do-db=database_1

replicate-do-db=database_2

replicate-do-db=database_3

replicate-do-db=database_4

#Error log

On this we round off with editing and restart MySQL with a new config.

# /usr/local/etc/rc.d/mysql-server restart

Now you need to add a user to the Master for the Slave server.

For replication, REPLICATION SLAVE rights will suffice. Login as root to the MySQL server.

# mysql -uroot -p

Create a user:

mysql> use mysql;

mysql>CREATE USER 'replica'@'ip_address_slave_server';

mysql>GRANT REPLICATION SLAVE ON*.* TO 'replica'@'ip_address_slave_server' IDENTIFIED BY 'password_for_user_replica';

Now you can either reboot the server or say

mysql>FLUSH PRIVILEGES;

2. Create a dump of the required databases:

All bases.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > /usr/home/Timur/dump.sql

certain bases.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -B DATABASE DATABASE1 DATABASE2 DATABASE3 > /usr/home/Timur/dump.sql

3. We look at which binlog to use and its position:

# head -n80 /usr/home/Timur/dump.sql | grep "MASTER_LOG_POS"

- CHANGE MASTER TO MASTER_LOG_FILE=' mysql-bin.000049‘,MASTER_LOG_POS= 107 ;

Please write it down!!!

4. Click the dump and transfer it to the Slave server:

# gzip /usr/home/Timur/dump.sql

We transfer.

# scp /usr/home/Timur/dump.sql.gz _address_slave_server:/usr/home/Timur

5. Setting up the Slave server (my.cnf).

server-id=2

binlog - format = mixed

log-bin=/var/log/mysql/mysql-bin

expire_logs_days = 30

#Binglog Slave

relay-log = /var/log/mysql/mysql-relay.log
relay-log-index = /var/log/mysql/mysql-relay-bin.index

#Instructs the downstream server to record updates that occur on the downstream server in a binary log. This option is disabled by default. It should be enabled if you want to daisy chain slave servers.

log-slave-updates=1

#Set databases to read-only. This option does not apply to superusers!!!

read-only = 1

#Skip duplicate entries. After Seconds_Behind_Master becomes 0, comment out and reboot SLAVE

slave-skip-errors=all

# Specify which databases we need to replicate

replicate-do-db=database_1

replicate-do-db=database_2

replicate-do-db=database_3

replicate-do-db=database_4

#Error log

log-error=/var/log/mysql/mysqld-error.log

#So that the Slave does not start when the server starts. You can start it manually START SLAVE;

skip-slave-start = On

Restart the server (MySQL).

6. Upload the dump to Slave and start replication:

Let's unzip.

# gunzip /usr/local/Timur/dump.sql.gz

Loading the dump.

# mysql -uroot -p< /usr/local/Timur/dump.sql

We tell Slave where to pull the data from and start. MASTER_LOG_FILE and MASTER_LOG_POS take what we wrote down when dumping bases on Master 😉

mysql>CHANGE MASTER TO MASTER_HOST= ‘<>' , MASTER_USER = 'replica' , MASTER_PASSWORD = 'password_for_user_replica', MASTER_LOG_FILE= ‘mysql-bin.000049‘ , MASTER_LOG_POS = 107 ; START SLAVE ;

We watch as a team SHOW SLAVE STATUS\G Have we all started?

mysql> SHOW SLAVE STATUS\G
****************************** 1st row ******************** *******
Slave_IO_State: Waiting for master to send event
Master_Host: This is the address of the Master server
Master_User: replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000049
Read_Master_Log_Pos: 1919771
Relay_Log_File: mysql-relay.000050
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000049
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: database_1,database_2,database_3,database_4,database_1,database_2,database_3,database_4
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1919771
Relay_Log_Space: 3125
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 5
1 row in set (0.00 sec)

Everything started up.

Should grow Exec_Master_Log_Pos: 1919771

If an error occurs, you can skip it by running:

mysql> STOP SLAVE;SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;

This is a brief description of how to set up full replication on your MySQL server. It is assumed that all databases will be replicated and replication has not been previously configured. In order to complete the steps here, you will need to a short time stop the master server.

This is the easiest way to install a slave server, but it is not the only one. For example, if you already have an image of the parent server, the server ID is already set on the parent server, and logging is being done, the slave server can be installed without stopping the parent server or even setting update locks (for more information, see See section 4.10.7 Often replication FAQs.

To become a real MySQL replication guru, we recommend that you first learn, understand, and try all the commands mentioned in See section 4.10.6 Replication-Related SQL Commands. See section 4.10.5 Replication Options in `my.cnf" .

Make sure the master and slave server(s) have the latest version of MySQL installed. Use version 3.23.29 or higher. Previous releases used a different binary log format and contained bugs that have been fixed in newer releases. Big request: please don't send bug reports without checking if this bug is present in the latest release.
Set up a single replication user on the master server with FILE privilege (in MySQL versions below 4.0.2) or REPLICATION SLAVE privilege in newer MySQL versions. This user must also have permission to connect from all downstream servers. If the user will only perform replication (recommended), they do not need to be granted any additional privileges. For example, to create a user named repl that can access the head server from any host, you can use the following command: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
Shut down MySQL on the master server. mysqladmin -u root -p shutdown
Create an image of all data on the master server. The easiest way to do this (on Unix) is to create with tar an archive of its entire data directory. The exact location of the data directory depends on your installation. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Windows users can use WinZIP or a similar program to create a data directory archive.
In my.cnf on the master server, add entries to the entry section log-bin and server-id=unique number to the section and restart the server. It is very important that the ID of the slave server is different from the ID of the parent server. We can think of the server-id as an IP address - it uniquely identifies the server among replication members. log-bin server-id=1
Restart MySQL on the master server.
Add the following to my.cnf on the slave server(s): master-host= master-user= master-password= master-port= server-id= replacing the values in with the values appropriate for your system. The server-id values must be different on each server involved in replication. If server-id is not defined, it will be set to 1, if master-host is also not defined, it will be set to 2. Note that if server-id is omitted, then the master server will refuse connections to all slave servers , and the slave server - to refuse connection to the parent server. Therefore, you can only omit setting the server-id value if you are backing up using a binary log.
Copy the snapshot data to the data directory on the slave server(s). Make sure the permissions for files and directories are correct. The user running MySQL as must be able to read and write data to them in the same way as on the master server.
Restart the slave(s) server(s).

Once these steps have been completed, the downstream server(s) should connect to the upstream server and adjust their data to reflect any changes that have occurred on the upstream server since the image was taken.

If the server -id is not set for the downstream server, the following error will be logged in the error log:

Warning: one should set server_id to a non-0 value if master_host is set. The server will not act as a slave. (Warning: if master_host is set, server_id must be set to a non-zero value. The server will not act as a slave server.)

If the master server ID is not set, the slave servers will not be able to connect to the master server.

If a downstream server is unable to replicate for any reason, the corresponding error messages can be found in the error log on the downstream server.

After the slave server starts replicating, a `master.info" file will appear in the same directory as the error log. The `master.info" file is used by the slave server to keep track of which binary log entries of the master server have been processed. Do not delete or edit this file unless you are sure it is necessary. Even if there is such confidence, it is still better to use the CHANGE MASTER TO command.

replication- a technique used in the architecture of systems operating under load, the result of which is the distribution of the load when working with one database on several servers. MySQL MASTER SLAVE replication is used more often, but a second type of replication is also used - Master-Master.

What is MySQL MASTER SLAVE replication and what is it used for?

replication master-slave involves duplicating data on a slave MySQL server, such duplication is carried out for the most part in order to ensure reliability. In case of failure of the Master server, its functions are switched to the Slave.

Replication can also be performed to improve system performance, but performance is almost always secondary here.
When an application works with a database, the most frequent operations are operations SELECT- requests for reading data, data modification - requests DELETE, INSERT, UPDATE, ALTER statistically occurs much less often.

To prevent data loss in the event of a failure of one of the servers, operations to change information in tables are always processed by the Master server. The changes are then replicated to the Slave. Reading can be done from the server playing the role of Slave.
Due to this, you can get a performance gain along with reliability.

The solution is popular, but not always applicable, since replication may experience delays - if this happens, information also has to be read from the Master server.

The direction of requests of a certain type to a particular database server is in any case implemented at the application level.

If you do the division SELECT queries and all the rest at the program level, sending them to the desired server if one of them fails, the application that serves the infrastructure will be inoperable. For this to work, you need to provide a more complex scheme and reserve each of the servers.

Replication is for fault tolerance, not for scaling.

MySQL MASTER SLAVE replication - setup on Debian

We will use two servers with addresses:

Master server 192.168.0.1
Slave server 192.168.0.2

For demonstration, VDS connected to a local network are used.
To always know for sure on which server we are executing this or that command, we will edit the /etc/hosts files on both servers

192.168.0.1 master

192.168.0.2 slave

We will replace the existing values in /etc/hostname with master and slave, respectively, so that the changes take effect, we will restart the server.

1. We make settings on the master server.

[email protected]:/#

Editing the main database server configuration file

mcedit /etc/mysql/my.cnf

Select the server ID - you can specify any number, the default is 1 - just uncomment the line

server-id = 1

Set the path to the binary log - also specified by default, uncomment

We set the name of the database that we will replicate to another server

binlog_do_db = db1

Restart Mysql so that the configuration file is re-read and the changes take effect:

/etc/init.d/mysql restart

2. Set the user the necessary rights

Go to the database server console:

We give the user on the slave server the necessary rights:

GRANT REPLICATION SLAVE ON *.* TO "slave_user"@"%" IDENTIFIED BY "123";

Locking all tables in the database

FLUSH TABLES WITH READ LOCK;

Check the status of the Master server:

3. Create a database dump on the server

Create a database dump:

mysqldump -u root -p db1 > db1.sql

Unlock tables in mysql console:

4. Transfer the database dump to the Slave server

scp db1.sql [email protected]:/home

We perform further actions on the Slave server

[email protected]:/#

5. Creating a database

Loading the dump:

mysql -u root -p db1< db1.sql

6. Making changes to my.cnf

mcedit /etc/mysql/my.cnf

Assign an ID by incrementing the value set on the Master Server

server-id = 2

Set the path to the relay log

relay-log = /var/log/mysql/mysql-relay-bin.log

and the bin path to the log on the Master server

log_bin = /var/log/mysql/mysql-bin.log

Specify the base

binlog_do_db = db1

Restarting the service

/etc/init.d/mysql restart

7. Set the connection to the Master server

CHANGE MASTER TO MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

We start replication on the slave server:

You can check the operation of replication on the Slave by querying:

****************************** 1st row ******************** *******
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.1
master_user: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 row in set (0.00 sec)

Since no errors occurred, we can conclude that replication is configured correctly.

Is good tool scaling, but as the main disadvantage it has desynchronization of data copying and delays, which can be critical.

They can be completely avoided by using more modern solution. It is easy to set up, reliable, and eliminates the need to manually copy database dumps.

These days, the MySQL database is used almost everywhere, wherever possible. It is impossible to imagine a site that would work without MySQL. Of course, there are some exceptions, but this database system occupies the bulk of the market. And the most popular implementation is MariaDB. When the project is small, a single server is enough to run it, on which all services are located: a web server, a database server, and mail server. But when the project gets bigger, it may be necessary to dedicate a separate server for each service, or even split one service into several servers, such as MySQL.

In order to maintain a synchronous state of the databases on all servers, replication must be used simultaneously. In this article, we will look at how MySQL replication is configured using MariaDB Galera Cluster.

WHAT IS MARIADB GALERA?

MariaDB Galera is a master-master cluster system for MariaDB. Since MariaDB 10.1 software Galera Server and MariaDB Server come in one package, so you get all the software you need right away. On this moment MariaDB Galera can only work with InnoDB and XtraDB database engines. One of the benefits of using replication is the addition of redundancy to the site database. If one of the databases fails, you can immediately switch to another. All servers maintain a synchronized state with each other and guarantee no lost transactions.

Main features of MariaDB Galera:

Replication with constant synchronization;
Automatic merging of nodes;
Ability to connect multiple master nodes;
Support for writing to any of the nodes;
Transparent parallel replication;
Read and write scalability, minimal latency;
Failed nodes are automatically disconnected from the cluster;
You cannot block access to tables.

SETUP MYSQL REPLICATION

In this tutorial, we will use Ubuntu 16.04 and MariaDB version 10.1 for the example. Before you begin, completely update the system:

sudo apt-get update-y
sudo apt-get upgrade -y

Since we will be deploying our configuration to multiple nodes, we need to perform update operations on all of them. If the MariaDB database server is not already installed, it must be installed. First, add the repository and its key:

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

sudo add-apt-repository "deb http://ftp.utexas.edu/mariadb/repo/10.1/ubuntu xenial main"

sudo apt-get update -y

When the package list update is complete, install MariaDB with the command:

sudo apt install mariadb-server rsync -y

We need the rsync package to perform direct synchronization. Once the installation is complete, you need to secure the database using the mysql_secure_installation script:

sudo mysql_secure_installation

By default, guest login is allowed, there is a test database, and no password is set for the root user. All this needs to be corrected. Read more in the article. In short, you will need to answer a few questions:

Enter current password for root (enter for none):
Change the root password? n
Remove anonymous users? Y
Disallow root login remotely? Y
Remove test database and access to it? Y
Reload privilege tables now? Y

When everything is ready, you can proceed to setting up the nodes between which the mysql databases will be replicated. First, let's look at setting up the first node. You can put all the settings in my.cnf, but it would be better to create separate file for these purposes in the /etc/mysql/conf.d/ folder.

Add these lines:

binlog_format=ROW

innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

wsrep_on=ON

wsrep_sst_method=rsync
# Galera Node Configuration
wsrep_node_address="192.168.56.101"
wsrep_node_name="Node1"

Here the address 192.168.56.101 is the address of the current node. Then go to another server and create the same file there:

sudo vi /etc/mysql/conf.d/galera.cnf

binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Galera Cluster Configuration
wsrep_cluster_name="galera_cluster"
wsrep_cluster_address="gcomm://192.168.56.101,192.168.56.102"
# Galera Synchronization Configuration
wsrep_sst_method=rsync
# Galera Node Configuration
wsrep_node_address="192.168.56.102"
wsrep_node_name="Node2"

Similarly, here the node address is 192.168.0.103. Let's dwell on the example with two servers, since this is enough to demonstrate the operation of the system, and you can add another server by entering an additional IP address in the wsrep_cluster_address field. Now consider what the values of the main parameters mean and proceed to the launch:

binlog_format- the format of the log in which requests will be saved, the row value indicates that binary data will be stored there;
default-storage-engine- engine SQL tables which we will use;
innodb_autoinc_lock_mode- AUTO_INCREMENT value generator operation mode;
bind address- ip address where the program will listen for connections, in our case, all ip addresses;
wsrep_on- includes replication;
wsrep_provider- library with which replication will be performed;
wsrep_cluster_name - cluster name, must match on all nodes;
wsrep_cluster_address- list of addresses of servers between which mysql databases will be replicated, separated by commas;
wsrep_sst_method- the transport that will be used for data transmission;
wsrep_node_address- ip address of the current node;
wsrep_node_name- the name of the current node.

Setting MySQL replication almost completed. The last touch left before launch is the firewall setting. First, enable the iptables rule management tool in Ubuntu - UFW:

Then open these ports:

sudo ufw allow 3306/tcp
sudo ufw allow 4444/tcp
sudo ufw allow 4567/tcp
sudo ufw allow 4568/tcp
sudo ufw allow 4567/udp

LAUNCH MARIADB GALERA

After successfully setting up all the nodes, we just have to start the Galera cluster on the first node. Before we can start the cluster, you need to make sure that the MariaDB service is stopped on all servers:

sudo galera_new_cluster