August 2016 – Stephen R Lang

Setting up MySQL Master Slave Replication with LVM snapshots

This article is part of a series of setting up MySQL replication. As with most things, there is always more than one way to do something. In the case of setting up MySQL replication, or rebuilding it, some options are better than others depending on your use case.

The articles in the series are below:
Setting up MySQL Replication using mysqldump
Setting up MySQL Replication using Percona XtraBackup
Setting up MySQL Replication using Rsync
Setting up MySQL Replication using LVM snapshots

This guide will document how to setup MySQL Master / Slave Replication using LVM snapshots. So why use LVM snapshots for setting up or rebuilding MySQL Replication? If your databases and tables are large, you can greatly limit the downtime felt to the application using LVM snapshots. This should still be performed during a scheduled maintenance window as you will be flushing the tables with READ LOCK.

Some prerequisites before proceeding are below:

1. Confirming that your datadir is indeed configured on a partition running LVM:

[root@db01 ~]# lvs

2. Confirming that you have enough free space in your Volume Group for the LVM snapshot:

[root@db01 ~]# vgs

So in the sections below, we’ll configure the Master and Slave MySQL server for replication, then we’ll use an LVM snapshot for syncing the databases over to db02.

Setup the Master MySQL server

Configure the my.cnf as shown below:

log-bin=/var/lib/mysql/db01-binary-log
expire-logs-days=5
server-id=1

Then restart MySQL to apply the settings:

# CentOS / RHEL:
[root@db01 ~]# service mysqld restart

# Ubuntu / Debian:
[root@db01 ~]# service mysql restart

Finally, grant access to the Slave so it has access to communicate with the Master:

mysql> GRANT REPLICATION SLAVE ON *.* to 'repl’@’10.x.x.x’ IDENTIFIED BY 'your_password';

Setup the Slave MySQL server

Configure the my.cnf as shown below:

relay-log=/var/lib/mysql/db02-relay-log
relay-log-space-limit = 4G
read-only=1
server-id=2

Then restart MySQL to apply the settings:

# CentOS / RHEL:
[root@db02 ~]# service mysqld restart

# Ubuntu / Debian:
[root@db02 ~]# service mysql restart

Use LVM snapshots for syncing over the databases

For reference, the rest of this guide will refer to the servers as follows:

db01 - Master MySQL Server
db02 - Slave MySQL Server

On db02 only, rename the existing MySQL datadir, and create a fresh folder:

[root@db02 ~]# service mysqld stop
[root@db02 ~]# mv /var/lib/mysql /var/lib/mysql.old
[root@db02 ~]# mkdir /var/lib/mysql
[root@db02 ~]# chown mysql:mysql /var/lib/mysql

On db01 only, create a snapshot script for MySQL to ensure things move quick to limit downtime:

[root@db01 ~]# vim /root/lvmscript.sql
FLUSH LOCAL TABLES;
FLUSH LOCAL TABLES WITH READ LOCK;
SHOW MASTER STATUS;
SYSTEM lvcreate -L 10G -s vglocal00/mysql00 -n mysqlsnapshot00 3>&-
SHOW MASTER STATUS;
UNLOCK TABLES;

On db01 only, during a scheduled maintenance window, run the script to create the LVM snapshot, and be sure to take note of master status information as that will be needed later:

[root@db01 ~]# mysql -t < /root/lvmscript.sql

On db01 only, mount the snapshot, sync over the contents to db02, and then remove the snapshot since it will no longer be needed:

[root@db01 ~]# mount /dev/mapper/vglocal00-mysqlsnapshot00 /mnt
[root@db01 ~]# rsync -axvz --delete -e ssh /mnt/ root@db02:/var/lib/mysql/
[root@db01 ~]# umount /mnt
[root@db01 ~]# lvremove vglocal00/mysqlsnapshot00

On db02 only, remove the stale mysql.sock file, startup MySQL, configure db02 to connect to db01 using the information from the show master status command you ran on db01 previously, and start replication:

[root@db02 ~]# rm /var/lib/mysql/mysql.sock
[root@db02 ~]# service mysqld start
[root@db02 ~]# mysql
mysql> CHANGE MASTER TO MASTER_HOST='10.x.x.x', MASTER_USER='repl', MASTER_PASSWORD='your_password', MASTER_LOG_FILE='db01-bin-log.000001', MASTER_LOG_POS=1456783;
mysql> start slave;
mysql> show slave status\G
...
        Slave_IO_Running: Yes
        Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0
...

If those values are the same as what is shown above, then replication is working properly! Perform a final test by creating a test database on the Master MySQL server, then check to ensure it shows up on the Slave MySQL server. Afterwards, feel free to drop that test database on the Master MySQL server.

From here, you should be good to go! Just be sure to setup a monitoring check to ensure that replication is always running and doesn’t encounter any errors. A very basic MySQL Replication check can be found here:
https://github.com/stephenlang/system-health-check

Setting up MySQL Master Slave Replication with rsync

This guide will document how to setup MySQL Master / Slave Replication using Rsync. So why use Rsync for setting up or rebuilding MySQL Replication? If your databases and tables are large, but fairly quiet, you can limit the downtime felt by syncing over the majority of the content live with Rsync, then you perform a final Rsync during a scheduled maintenance window to catch any of the tables that may have changed by using a READ LOCK. This is also very useful when you do not have enough disk space available on db01 to perform a traditional backup using mysqldump or using Percona’s XtraBackup as the data is being rsync’ed directly over to db02.

This is a fairly simplistic method of setting of MySQL Replication, or rebuilding it. So in the sections below, we’ll configure the Master and Slave MySQL server for replication, then we’ll sync over the databases.

Setup the Master MySQL server

Configure the my.cnf as shown below:

log-bin=/var/lib/mysql/db01-binary-log
expire-logs-days=5
server-id=1

Then restart MySQL to apply the settings:

# CentOS / RHEL:
[root@db01 ~]# service mysqld restart

# Ubuntu / Debian:
[root@db01 ~]# service mysql restart

Finally, grant access to the Slave so it has access to communicate with the Master:

mysql> GRANT REPLICATION SLAVE ON *.* to 'repl’@’10.x.x.x’ IDENTIFIED BY 'your_password';

Setup the Slave MySQL server

Configure the my.cnf as shown below:

relay-log=/var/lib/mysql/db02-relay-log
relay-log-space-limit = 4G
read-only=1
server-id=2

Then restart MySQL to apply the settings:

# CentOS / RHEL:
[root@db02 ~]# service mysqld restart

# Ubuntu / Debian:
[root@db02 ~]# service mysql restart

Rsync the databases

For reference, the rest of this guide will refer to the servers as follows:

db01 - Master MySQL Server
db02 - Slave MySQL Server

On db02 only, rename the existing MySQL datadir, and create a fresh folder:

[root@db02 ~]# service mysqld stop
[root@db02 ~]# mv /var/lib/mysql /var/lib/mysql.old
[root@db02 ~]# mkdir /var/lib/mysql

On db01 only, perform the initial sync of data over to db02:

[root@db01 ~]# rsync -axvz /var/lib/mysql/ root@db02:/var/lib/mysql/

Now that you have the majority of the databases moved over, its time to perform the final sync of data during a scheduled maintenance window as you will be flushing the tables with a READ LOCK, then syncing over the data.

On db01 only, flush the tables with READ LOCK, and grab the master status information as we’ll need that later. It is critical that you do NOT exit MySQL while the READ LOCK is in place. Once you exit MySQL, the READ LOCK is removed. Therefore, the example below will run this in a screen session so it continues to run in the background:

[root@db01 ~]# screen -S mysql
[root@db01 ~]# mysql
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
(detach screen session with ctrl a d)

On db01 only, perform the final rsync of the databases to db02, then release the READ LOCK on db01:

[root@db01 ~]# rsync -axvz --delete /var/lib/mysql/ root@db02:/var/lib/mysql/
[root@db01 ~]# screen -dr mysql
mysql> quit
[root@db01 ~]# exit

[root@db02 ~]# rm /var/lib/mysql/mysql.sock
[root@db02 ~]# rm /var/lib/mysql/auto.cnf
[root@db02 ~]# service mysqld start
[root@db02 ~]# mysql
mysql> CHANGE MASTER TO MASTER_HOST='10.x.x.x', MASTER_USER='repl', MASTER_PASSWORD='your_password', MASTER_LOG_FILE='db01-bin-log.000001', MASTER_LOG_POS=1456783;
mysql> start slave;
mysql> show slave status\G
...
        Slave_IO_Running: Yes
        Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0
...

Setting up MySQL Master Slave Replication with Percona XtraBackup

This guide will document how to setup MySQL Master / Slave Replication using Percona XtraBackup. I strongly recommend reviewing the official documentation on Percona’s site at:
How innobackupex works
Official guide for setting up replication with Percona XtraBackup

So why use Percona XtraBackup for setting up or rebuilding MySQL Replication? Percona XtraBackup performs hot backups on unmodified versions of MySQL, MariaDB and Percona on versions 5.1 and above.

This basically means that you can generally run the backup on InnoDB tables without having the interruption/downtime associated with table locking on your site, like you would normally experience using MySQLdump. However, it is critical to note that table locking WILL still occur on tables using MyISAM and other non-InnoDB tables.

Some important prerequisites before proceeding:

1. Recommend using Percona XtraBackup on MySQL, MariaDB, and Percona 5.5 and above. Example:

[root@db01 ~]# mysql -V
mysql  Ver 14.14 Distrib 5.5.49, for Linux (x86_64) using readline 5.1

2. Confirm the MySQL client libraries are installed.

3. The MySQL master and slave server both have the same innodb-log-file-size defined in the my.cnf, and that they are at least 48M in size.

[root@db01 ~]# grep innodb-log-file-size /etc/my.cnf 
innodb-log-file-size = 128M

4. The master does not have symlinks in the MySQL datadir that could cause space to be underestimated. You can check for this by running:

[root@db01 ~]# du -sch /var/lib/mysql/ $(for i in $(find /var/lib/mysql/ -type l); do readlink $i; done)

5. Confirm there is only one instance of MySQL running on the master. When you have multiple versions of MySQL running, its easy to backup the wrong data.

6. Event scheduler is not enabled on the slave. You can check for this by running:

[root@db01 ~]# mysql
mysql> show variables where Variable_name like 'event_scheduler';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| event_scheduler | OFF   |
+-----------------+-------+
1 row in set (0.00 sec)

7. Confirm that no tables are using the MEMORY engine on the master. You can check for this by running:

[root@db01 ~]# mysql
mysql> select concat('ALTER TABLE `',table_schema,'`.`',table_name,'` ENGINE=INNODB;') from information_schema.tables where engine='memory' and table_schema not in ('information_schema','performance_schema');
Empty set (0.03 sec)

8. Confirm that both the master and slave server have NTP enabled and running, and that both servers are using the same timezone. Example:

[root@db01 ~]# ps waux |grep ntp
ntp       7276  0.0  0.0  30740  1684 ?        Ss   Aug09   0:02 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
[root@db01 ~]# date
Tue Aug 30 05:06:50 UTC 2016

9. Confirm the master and slave have the same binlog_format and expire_log_days variables in the my.cnf when binary logging is enabled on the slave. Example:

[root@db01 ~]# egrep 'binlog-format|expire-logs-days' /etc/my.cnf 
expire-logs-days = 5
# binlog-format = STATEMENT

Now that you confirmed that the prerequisites are out of the way, proceed with setting up MySQL Replication.

Setup the Master MySQL server

Configure the my.cnf as shown below:

log-bin=/var/lib/mysql/db01-binary-log
expire-logs-days=5
server-id=1

Then restart MySQL to apply the settings:

# CentOS / RHEL:
[root@db01 ~]# service mysqld restart

# Ubuntu / Debian:
[root@db01 ~]# service mysql restart

Finally, grant access to the Slave so it has access to communicate with the Master:

mysql> GRANT REPLICATION SLAVE ON *.* to 'repl’@’10.x.x.x’ IDENTIFIED BY 'your_password';

Setup the Slave MySQL server

Configure the my.cnf as shown below:

relay-log=/var/lib/mysql/db02-relay-log
relay-log-space-limit = 4G
read-only=1
server-id=2

Then restart MySQL to apply the settings:

# CentOS / RHEL:
[root@db02 ~]# service mysqld restart

# Ubuntu / Debian:
[root@db02 ~]# service mysql restart

Install Percona XtraBackup

For reference, the rest of this guide will refer to the servers as follows:

db01 - Master MySQL Server
db02 - Slave MySQL Server

On db01 only, install Percona XtraBackup using Percona’s repos:

[root@db01 ~]# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm
[root@db01 ~]# yum install percona-xtrabackup-24

On db01 only, confirm it installed XtraBackup version 2.3 or newer:

[root@db01 ~]# xtrabackup --version

On db01 only, to prevent future issues, it is extremely important to remove or disable the yum repo for Percona:

[root@db01 ~]# yum remove percona-release

Setup MySQL replication using Percona XtraBackup

On db02 only, rename the existing MySQL datadir, and create a fresh folder:

[root@db02 ~]# service mysqld stop
[root@db02 ~]# mv /var/lib/mysql /var/lib/mysql.old
[root@db02 ~]# mkdir /var/lib/mysql

On db01 only, create the backup, make the snapshot consistent by applying the log, and rsync it over to db02:

[root@db01 ~]# mkdir /root/perconabackup
[root@db01 ~]# innobackupex /root/perconabackup
[root@db01 ~]# innobackupex --apply-log /root/perconabackup/TIMESTAMP/
[root@db01 ~]# rsync -axvz -e ssh /root/perconabackup/TIMESTAMP/ root@db02:/var/lib/mysql/

On db02, fix the ownership of the datadir, startup MySQL, and grab the binlog name and position:

[root@db02 ~]# chown -R mysql:mysql /var/lib/mysql
[root@db02 ~]# service mysqld start
[root@db02 ~]# cat /var/lib/mysql/xtrabackup_binlog_info
db01-bin-log.000001     1456783

On db02, startup slave replication:

[root@db02 ~]# mysql
mysql> CHANGE MASTER TO MASTER_HOST='10.x.x.x', MASTER_USER='repl', MASTER_PASSWORD='your_password', MASTER_LOG_FILE='db01-bin-log.000001', MASTER_LOG_POS=1456783;
mysql> start slave;
mysql> show slave status\G
...
        Slave_IO_Running: Yes
        Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0
...

VMware disk expansion

There are a number of ways to add more disk space to a VM on VMware. This guide will discuss 5 different ways to handle expanding the existing disk in VMware, which are:

- Expand existing disk to LVM (Not previously expanded)
- Expand existing disk to LVM (Previously expanded)
- Expand existing disk with LVM not in use (Dangerous)
- Add a new disk into an existing LVM Volume Group
- Add a new disk as a separate mount point

Many VMware solutions set their disk labels to MBR, so for this guide, we’ll be making extensive use of fdisk. If your disk label is set to GPT, please use caution when following this guide!

As with any disk expansion operations, always be sure you have solid backups in place in case something goes wrong!

Expand existing disk to LVM (Not previously expanded)

Assuming the VM’s disk has already been expanded within VMware, you have to rescan the specific SD device to detect the new properties. You can do this by:

[root@web01 ~]# echo 1 > /sys/block/sdX/device/rescan
or
[root@web01 ~]# echo 1 > /sys/bus/scsi/drivers/sd/SCSI-ID/block/device/rescan
or
[root@web01 ~]# echo 1 > /sys/bus/scsi/drivers/sd/SCSI-ID/block\:sdX/device/rescan

Whether the added a new disk, or expanded an existing one, you can usually detect the change by:

[root@web01 ~]# dmesg|tail
...
sd 2:0:0:0: [sda] 67108864 512-byte logical blocks: (34.3 GB/32.0 GiB)
sd 2:0:0:0: [sda] Cache data unavailable
sd 2:0:0:0: [sda] Assuming drive cache: write through
sda: detected capacity change from 17179869184 to 34359738368

Now you need to determine if the volume has actually be expanded. Check for the ‘resize_inode’ flag by:

[root@web01 ~]# tune2fs -l /dev/vglocal00/lvroot | grep -i "^filesystem features"

Check to see if storage has increased in size yet first by:

[root@web01 ~]# fdisk -cul /dev/sda
[root@web01 ~]# pvs
[root@web01 ~]# vgs
[root@web01 ~]# lvs
[root@web01 ~]# df -h

Once the root disk has been expanded in VMware, rescan the disk which should now show additional sectors have been added:

[root@web01 ~]# echo 1 > /sys/block/sda/device/rescan
[root@web01 ~]# fdisk -cul /dev/sda

Now we need to add a partition for the new space. As fdisk only allows 4 primary partitions, we are going to use extended partitions so we can create logical partitions to hold the new space:

[root@web01 ~]# fdisk -cu /dev/sda
p
n
e (extended)
3
enter
enter
n
l (logical)
enter
enter
p
w

Now rescan the partitions so the system can detect the new one without rebooting:

[root@web01 ~]# ls /dev/sda*
[root@web01 ~]# partx -l /dev/sda
[root@web01 ~]# partx -v -a /dev/sda # There may be some errors here, ignore.
[root@web01 ~]# partx -l /dev/sda
[root@web01 ~]# ls /dev/sda*

Now setup LVM on that new partition, and add it to the existing volume group and expand the logical volume:

[root@web01 ~]# pvcreate /dev/sda5
[root@web01 ~]# vgs
[root@web01 ~]# vgextend YOUR_VG_NAME /dev/sda5
[root@web01 ~]# pvdisplay /dev/sda5 | grep Free
  Free PE               4095
[root@web01 ~]# lvextend --extents +4095 -n /dev/YOUR_VG_NAME/lv_root

Finally, expand the filesystem doing an online resize:

[root@web01 ~]# resize2fs /dev/YOUR_VG_NAME/lv_root
[root@web01 ~]# df -h |grep root

Expand existing disk to LVM (Previously expanded)

If there is a VM where a previous expansion already took place, or otherwise is already on an extended partition with the first (only) logical partition taking up all the room, then this is the section you want.

Once the root disk has been expanded in VMware, rescan the disk which should now show additional sectors have been added:

# Print out disk information
[root@web01 ~]# fdisk -cul /dev/sda

# Then rescan the device
[root@web01 ~]# echo 1 > /sys/block/sdX/device/rescan
or
[root@web01 ~]# echo 1 > /sys/bus/scsi/drivers/sd/SCSI-ID/block/device/rescan
or
[root@web01 ~]# echo 1 > /sys/bus/scsi/drivers/sd/SCSI-ID/block\:sdX/device/rescan

# Print out disk information to confirm it detected the additional space
[root@web01 ~]# fdisk -cul /dev/sda

Expand the existing extended partition:

[root@web01 ~]# parted /dev/sda
unit s
pri
  Number  Start      End        Size       Type      File system  Flags
   1      2048s      41431039s  41428992s  primary                lvm
   2      41431040s  41943039s  512000s    primary   ext3         boot
   3      41943040s  52428799s  10485760s  extended
   5      41945088s  52428799s  10483712s  logical
resize 3 41943040s -1  (Take whatever the extended start value is, and the number)
pri
quit

Now partition the new space, setup LVM, expand and resize the filesystem:

[root@web01 ~]# fdisk -cu /dev/sda
p
n
l (logical)
enter
enter
p
w

[root@web01 ~]# ls -hal /dev/sda*
[root@web01 ~]# partx -l /dev/sda
[root@web01 ~]# partx -v -a /dev/sda # There may be some errors here, ignore.
[root@web01 ~]# partx -l /dev/sda
[root@web01 ~]# ls -hal /dev/sda*

[root@web01 ~]# pvcreate /dev/sda6 # Or whatever the new partition was
[root@web01 ~]# vgs
[root@web01 ~]# vgextend YOUR_VG_NAME /dev/sda6
[root@web01 ~]# pvdisplay /dev/sda6 | grep Free
  Free PE               4607
[root@web01 ~]# lvextend --extents +4607 -n /dev/YOUR_VG_NAME/lv_root
[root@web01 ~]# df -h
[root@web01 ~]# resize2fs /dev/YOUR_VG_NAME/lv_root
[root@web01 ~]# df -h

Expand existing disk to without LVM (Dangerous)

This section assumes that LVM was never setup for the disk. Therefore you would need to recreate the partitions to use the new space.

Re-creating partitions is a high risk operation as there is there is the potential for data loss, so make sure you have known good backups you can restore to. And at the very least, snapshot your VM! It also requires a reboot to occur on the VM. Ideally, you should first check to see if an additional disk can simply be mounted to a different mount point instead.

First, list the current partitions:

[root@web01 ~]# fdisk -l

Now within VMware or on the SAN presenting the disk, expand the disk. Once that is done, we need to rescan the volume and confirm the new space:

[root@web01 ~]# echo 1 > /sys/block/sda/device/rescan
[root@web01 ~]# fdisk -l
     Device Boot      Start         End      Blocks   Id  System
  /dev/sda1   *           1          13      104391   83  Linux
  /dev/sda2              14         274     2096482+  83  Linux
  /dev/sda3             275         796     4192965   82  Linux swap / Solaris
  /dev/sda4             797        2610    14570955    5  Extended
  /dev/sda5             797        2610    14570923+  83  Linux

Using the example above, you will notice that the new partitions (4 and 5) end on the same cylinder (2610). So the extended and logical partitions need to be set to use the new space. So to attempt to help you in the event everything goes wrong, list out the following information and store it somewhere safe so you can refer to it later:

[root@web01 ~]# fdisk -l /dev/sda
[root@web01 ~]# df -h
[root@web01 ~]# cat /etc/fstab

Now hold on to your butts and expand the disks by deleting the partitions (which *shouldn’t* affect the underlining data), then recreate the partitions with the new sizes:

[root@web01 ~]# fdisk /dev/sda
d
5
d
4
n
e
(Pick original extended position (Should be default, just hit enter)
(Pick the new, much larger cylinder ending position (for default all space until end, hit enter)
n
5 (or it should just assume right now here)
(Pick original logical partition started point (should be default next cylinder, hit enter)
(Pick new, much larger cylinder ending position (just default all space until end, hit enter)
p (Double check everything, ensure starting cylinders to extended partition 4 and logical partition 5 have the SAME starting cylinder number
w

Now reboot the system so it can use the new space:

[root@web01 ~]# shutdown -r now

Then expand the filesystem:

[root@web01 ~]# df -h | grep sda5
  /dev/sda5              14G  2.6G   11G  21% /
[root@web01 ~]# resize2fs /dev/sda5
[root@web01 ~]# df -h | grep sda5
  /dev/sda5              19G  2.6G   15G  15% /

Add a new disk or into an existing LVM Volume Group

This section assumes the new disk is the second disk on the VM, and is enumerated as /dev/sdb. The disk will be added to an existing Volume Group, and we’ll use all the new space on the disk for the volume group and logical volume.

[root@web01 ~]# parted -s -- /dev/sdb mklabel gpt
[root@web01 ~]# parted -s -a optimal -- /dev/sdb mkpart primary 2048s -1
[root@web01 ~]# parted -s -- /dev/sdb align-check optimal 1
[root@web01 ~]# parted /dev/sdb set 1 lvm on
[root@web01 ~]# parted /dev/sdb unit s print
[root@web01 ~]# pvcreate --metadatasize 250k /dev/sdb1
[root@web01 ~]# vgs
[root@web01 ~]# vgextend YOUR_VG_NAME /dev/sdb1
[root@web01 ~]# pvdisplay /dev/sdb1 | grep Free
  Free PE               4095
[root@web01 ~]# lvextend --extents +4095 -n /dev/YOUR_VG_NAME/lv_root
[root@web01 ~]# df -h
[root@web01 ~]# resize2fs /dev/YOUR_VG_NAME/lv_root
[root@web01 ~]# df -h

Add a new disk as a separate mount point

This section assumes the new disk is the second disk on the VM, and it enumerated as /dev/sdb. We are going to use GPT and LVM as a best practice (even if the root disk/partition has the disk label set to MBR or is non-LVM). This example also uses the whole disk in one partition.

# RHEL/CentOS 5:  Scan for new disk, check for existing partitions
# setup gpt, align, and partition:
[root@web01 ~]# for x in /sys/class/scsi_host/host*/scan; do echo "- - -" > ${x}; done
[root@web01 ~]# parted /dev/sdb unit s print
[root@web01 ~]# fdisk -l /dev/sdb
[root@web01 ~]# parted /dev/sdb
mktable gpt
quit
[root@web01 ~]# parted -s -- /dev/sdb mkpart primary 2048s -1
[root@web01 ~]# parted /dev/sdb set 1 lvm on
[root@web01 ~]# parted /dev/sdb unit s print

# RHEL/CentOS 6:  Scan for new disk, check for existing partitions
# setup gpt, align, and partition:
[root@web01 ~]# for x in /sys/class/scsi_host/host*/scan; do echo "- - -" > ${x}; done
[root@web01 ~]# parted /dev/sdb unit s print
[root@web01 ~]# fdisk -l /dev/sdb
[root@web01 ~]# parted -s -- /dev/sdb mklabel gpt
[root@web01 ~]# parted -s -a optimal -- /dev/sdb mkpart primary 2048s -1
[root@web01 ~]# parted -s -- /dev/sdb align-check optimal 1
[root@web01 ~]# parted /dev/sdb set 1 lvm on
[root@web01 ~]# parted /dev/sdb unit s print

Now on both OS’s, setup LVM, format, and mount the volume to /mnt/data:

[root@web01 ~]# VGNAME=vglocal$(date +%Y%m%d)
[root@web01 ~]# LVNAME=lvdata01
[root@web01 ~]# MOUNTPOINT="/mnt/data"
[root@web01 ~]# FILESYSTEM=`mount | egrep "\ \/\ " | awk '{print $5}'`
[root@web01 ~]# pvcreate --metadatasize 250k /dev/sdb1
[root@web01 ~]# vgcreate ${VGNAME} /dev/sdb1
[root@web01 ~]# lvcreate --extents 100%VG -n ${LVNAME} ${VGNAME}
[root@web01 ~]# mkfs.${FILESYSTEM} /dev/mapper/${VGNAME}-${LVNAME}
[root@web01 ~]# mkdir ${MOUNTPOINT}
[root@web01 ~]# echo -e "/dev/mapper/${VGNAME}-${LVNAME}\t${MOUNTPOINT}\t${FILESYSTEM}\tdefaults\t0 0" >> /etc/fstab
[root@web01 ~]# mount -a
[root@web01 ~]# df -hP | grep "${VGNAME}-${LVNAME}"
/dev/mapper/vglocal20160830-lvdata01   16G   44M   15G   1% /mnt/data