Took me all day to figure this out. Xen 7.3 does not come with NFS support oddly. So you need to install it.
First you will surely need the epel repository
yum --enablerepo=extras install epel-release
Now you can install other packages.
yum --enablerepo=epel --enablerepo=base install nfs-utils
I also like MC so let’s install that too.
yum --enablerepo=epel --enablerepo=base install mc
Some useful commends to test NFS.
rpcinfo -s <IP>
showmount -e <IP>
Below is another alternative, but this one seems to be a better way to go.
Above needs to be done in my.cnf and not the “.d” folders.
Copy /etc/mysql/my.cnf to /etc/mysql/my2.cnf
Also copy conf.d and mysql.conf.d to conf2.d and mysql.conf2.d
Update all the files in them to point to new data location and lock file needs to be in the /tmp/ location.
Pointing to the New Data Location
MySQL has several ways to override configuration values. By default, the
datadir is set to
/var/lib/mysql in the
/etc/mysql/mysql.conf.d/mysqld.cnf file. Edit this file to reflect the new data directory:
sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf
Find the line that begins with
datadir= and change the path which follows to reflect the new location.
In our case, the updated file looks like the output below:/etc/mysql/mysql.conf.d/mysqld.cnf
. . . datadir=/var/lib/mysql2 . . .
This seems like the right time to bring up MySQL again, but there’s one more thing to configure before we can do that successfully.
We’ll need to tell AppArmor to let MySQL write to the new directory by creating an alias between the default directory and the new location. To do this, edit the AppArmor
sudo nano /etc/apparmor.d/tunables/alias
At the bottom of the file, add the following alias rule:/etc/apparmor.d/tunables/alias
. . . alias /var/lib/mysql/ -> /var/lib/mysql2/, . . .
For the changes to take effect, restart AppArmor:
sudo systemctl restart apparmor
Now we can start new MySQL
shell> mysqld_safe --defaults-file=/etc/mysql/mysql2.cnf &
In the recent past, for a variety of reasons, I occasionally had to change the IP address of a MySQL master in a replicated environment.
It was a major annoyance that it was not sufficient to just change the IP address in the MySQL configuration file for slaves and then restart the server. Instead, I basically had to start from scratch, setting up replication anew. There had to be an easier way.
Well, there is. What you basically need to do is ensure that the slave is fully caught up (to the point when it was disconnected from the master). Then, stop the slave, adjust slave parameters, and restart.
Which parameters, you ask? Well, the address of the master, the name of the master log file, and the position within the file. The latter two can be obtained by viewing the slave status:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Reconnecting after a failed master event read
1 row in set (0.00 sec)
The next step is to stop the slave:
mysql> STOP SLAVE;
Next comes the aforementioned change of replication parameters, which can be accomplished by issuing the following command:
mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.1',
The value of MASTER_HOST is, of course, the new IP address of the master. The MASTER_LOG_FILE and MASTER_LOG_POS values come from the output SHOW SLAVE STATUS command above.
Finally, restart the slave:
mysql> START SLAVE;
That’s it. Do verify though that the slave is working properly by reissuing the SHOW SLAVE STATUS command a few times, watching as the slave catches up with the master.