10.11. Recommended Practices Manually Setting the Time If you have to change the time on the bricks manually, then the geo-replication session and indexing must be disabled when setting the time on all the bricks. All bricks in a geo-replication environment must be set to the same time, as this avoids the out-of-time sync issue described in Section 10.3.4.1, "Setting Up your Environment for Geo-replication Session" . Bricks not operating on the same time setting, or changing the time while the geo-replication is running, will corrupt the geo-replication index. The recommended way to set the time manually is using the following procedure. Manually Setting the Time on Bricks in a Geo-replication Environment Stop geo-replication between the master and slave, using the following command: Stop geo-replication indexing, using the following command: Set a uniform time on all the bricks. Restart the geo-replication sessions, using the following command: Performance Tuning When the following option is set, it has been observed that there is an increase in geo-replication performance. On the slave volume, run the following command: Initially Replicating Large Volumes to a Remote Slave Locally using a LAN For replicating large volumes to a slave in a remote location, it may be useful to do the initial replication to disks locally on a local area network (LAN), and then physically transport the disks to the remote location. This eliminates the need of doing the initial replication of the whole volume over a slower and more expensive wide area network (WAN) connection. The following procedure provides instructions for setting up a local geo-replication session, physically transporting the disks to the remote location, and then setting up geo-replication over a WAN. Initially Replicating to a Remote Slave Locally using a LAN Create a geo-replication session locally within the LAN. For information on creating a geo-replication session, see Section 10.3.4.1, "Setting Up your Environment for Geo-replication Session" . Important You must remember the order in which the bricks/disks are specified when creating the slave volume. This information is required later for configuring the remote geo-replication session over the WAN. Ensure that the initial data on the master is synced to the slave volume. You can verify the status of the synchronization by using the status command, as shown in Section 10.4.3, "Displaying Geo-replication Status Information" . Stop and delete the geo-replication session. For information on stopping and deleting the the geo-replication session, see Section 10.4.5, "Stopping a Geo-replication Session" and Section 10.4.6, "Deleting a Geo-replication Session" . Important You must ensure that there are no stale files in /var/lib/glusterd/geo-replication/ . Stop and delete the slave volume. For information on stopping and deleting the volume, see Section 11.13, "Stopping Volumes" and Section 11.14, "Deleting Volumes" . Remove the disks from the slave nodes, and physically transport them to the remote location. Make sure to remember the order in which the disks were specified in the volume. At the remote location, attach the disks and mount them on the slave nodes. Make sure that the file system or logical volume manager is recognized, and that the data is accessible after mounting it. Configure a trusted storage pool for the slave using the peer probe command. For information on configuring a trusted storage pool, see Chapter 4, Adding Servers to the Trusted Storage Pool . Delete the glusterFS-related attributes on the bricks. This should be done before creating the volume. You can remove the glusterFS-related attributes by running the following command: Run the following command to ensure that there are no xattrs still set on the brick: After creating the trusted storage pool, create the Red Hat Gluster Storage volume with the same configuration that it had when it was on the LAN. For information on creating volumes, see Chapter 5, Setting Up Storage Volumes . Important Make sure to specify the bricks in same order as they were previously when on the LAN. A mismatch in the specification of the brick order may lead to data loss or corruption. Start and mount the volume, and check if the data is intact and accessible. For information on starting and mounting volumes, see Section 5.10, "Starting Volumes" and Chapter 6, Creating Access to Volumes . Configure the environment and create a geo-replication session from the master to this remote slave. For information on configuring the environment and creating a geo-replication session, see Section 10.3.4.1, "Setting Up your Environment for Geo-replication Session" . Start the geo-replication session between the master and the remote slave. For information on starting the geo-replication session, see Section 10.4, "Starting Geo-replication" . Use the status command to verify the status of the session, and check if all the nodes in the session are stable. For information on the status , see Section 10.4.3, "Displaying Geo-replication Status Information" .

Commands:
gluster volume geo-replication MASTER_VOL SLAVE_HOST :: SLAVE_VOL stop
gluster volume set MASTER_VOL geo-replication.indexing off
gluster volume geo-replication MASTER_VOL SLAVE_HOST :: SLAVE_VOL start
gluster volume set SLAVE_VOL batch-fsync-delay-usec 0
for i in `getfattr -d -m . ABSOLUTE_PATH_TO_BRICK 2>/dev/null | grep trusted | awk -F = '{print USD1}'`; do setfattr -x USDi ABSOLUTE_PATH_TO_BRICK ; done
getfattr -d -m . ABSOLUTE_PATH_TO_BRICK