› VitalPBX Community Support › General Discussion › HA High Availability not syncing the mysql database
- This topic has 2 replies, 2 voices, and was last updated 2 months ago by
Dan Hole.
- Post
-
- November 17, 2020 at 9:59 pm
I’m testing my HA setup and it doesnt appear to be syncing the databases.I originally installed version 3.03 last month and setup the HA cluster where i did some testing and all seemed ok
Today i went through the setup to install vitxi, i followed the guide which mentioned changing the hostname to match the fqdn (which i did not thinking about the impact on the cluster) I have now changed it back
I upgraded vitalpbx to 3.04 – Note this removes the cluster info showed when login into ssh in /etc/profile.d/vitalwelcome.sh
I then ran a bascul and updated the other node to 3.0.4
i then failed it back and created a user while pbx01 mas the master
ran bascul and checked the user where pbx02 was master and the user was not there.
Looking through the docs it mentions using the script to force a refresh so i tried that
And lastly to force a refresh of the cluster
[root@ vitalpbx1 ~]# pcs resource refresh --full
this also didnt help.
Looking at the database setup
<h2>
2.8.- Configure MariaDB Master-Master Replication.
</h2>
<h5>In Server 1 add this 2 line in file /etc/my.cnf.d/vitalpbx.cnf
</h5>It talk about adding the extra info to the config files this data is not there
My config file just contains
[mysqld]
innodb_buffer_pool_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 64M
innodb_log_buffer_size = 64M
bulk_insert_buffer_size = 64M
max_allowed_packet = 64M
Please can you let me know what i can do to re-establish my HA cluster.
Also can i get the lets-encrypt cert working in HA mode?
Regards
Dan
0
- Replies
-
- November 17, 2020 at 10:17 pm
You need to reconfigurate MariaDB ClusterIn Server A
mysql -uroot -e “DELETE FROM mysql.user WHERE User=”;
mysql -uroot -e “GRANT REPLICATION SLAVE ON *.* to vitalpbx_replica@’%’ IDENTIFIED BY ‘vitalpbx_replica’;“
mysql -uroot -e “FLUSH PRIVILEGES;“
mysql -uroot -e “FLUSH TABLES WITH READ LOCK;“
Get the filename and block in server A
mysql -uroot -e “show master status“ | awk ‘NR==2 {print $1}‘
mysql -uroot -e “show master status“ | awk ‘NR==2 {print $2}‘
Now in server A copy all the dabatabses
mysqldump -u root –all-databases > all_databases.sql
Copy the file all_databases.sql to server B
scp all_databases.sql root@$ip_server_b:/tmp/all_databases.sql
Go to Server B and restore the databses
mysql mysql -u root < /tmp/all_databases.sql
In Server B create the User
mysql -uroot -e “GRANT REPLICATION SLAVE ON *.* to vitalpbx_replica@’%’ IDENTIFIED BY ‘vitalpbx_replica’;”
mysql -uroot -e “FLUSH PRIVILEGES;”
mysql -uroot -e “FLUSH TABLES WITH READ LOCK;”
Get the filename and block in server B
mysql -uroot -e “show master status“ | awk ‘NR==2 {print $1}‘
mysql -uroot -e “show master status“ | awk ‘NR==2 {print $2}‘
Stop the slave, add Server-A to the Server-B and start slave (replace the three variables, $ip_server_A, $file_server_A, $position_server_A)
mysql -uroot -e “STOP SLAVE;”
mysql -uroot -e “CHANGE MASTER TO MASTER_HOST=’$ip_server_A’, MASTER_USER=’vitalpbx_replica’, MASTER_PASSWORD=’vitalpbx_replica’, MASTER_LOG_FILE=’$file_server_A’, MASTER_LOG_POS=$position_server_A;”
mysql -uroot -e “START SLAVE;”
Connect to Server A and follow the same steps (replace the three variables, $ip_server_B, $file_server_B, $position_server_B)
mysql -uroot -e “STOP SLAVE;“
mysql -uroot -e “CHANGE MASTER TO MASTER_HOST=’$ip_server_B‘, MASTER_USER=’vitalpbx_replica’, MASTER_PASSWORD=’vitalpbx_replica’, MASTER_LOG_FILE=’$file_server_B‘, MASTER_LOG_POS=$position_server_B;“
mysql -uroot -e “START SLAVE;“
DONE
0- November 19, 2020 at 10:37 am
That has fixed the issueI did also add the info the the config files first
[root@ vitalpbx<strong>1</strong>.local ~]# nano /etc/my.cnf.d/vitalpbx.cnf
[mysqld]
<strong>server-id=1</strong>
<strong>log-bin=mysql-bin</strong>
<strong>report_host = master1</strong>
Regards
Dan
-
This reply was modified 2 months ago by
Dan Hole.
0
- You must be logged in to reply to this topic.