Repository: incubator-hawq-docs Updated Branches: refs/heads/develop ab9161229 -> 01a982c03
general edit, and identify ambari procedures Project: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/commit/01a982c0 Tree: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/tree/01a982c0 Diff: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/diff/01a982c0 Branch: refs/heads/develop Commit: 01a982c031e6fefa2b7c9bb9df2cba65f8b19175 Parents: ab91612 Author: Lisa Owen <[email protected]> Authored: Wed Nov 2 14:26:27 2016 -0700 Committer: Lisa Owen <[email protected]> Committed: Wed Nov 2 14:26:27 2016 -0700 ---------------------------------------------------------------------- admin/MasterMirroring.html.md.erb | 107 ++++++++++++++++++--------------- 1 file changed, 58 insertions(+), 49 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/01a982c0/admin/MasterMirroring.html.md.erb ---------------------------------------------------------------------- diff --git a/admin/MasterMirroring.html.md.erb b/admin/MasterMirroring.html.md.erb index c731427..b9352f0 100644 --- a/admin/MasterMirroring.html.md.erb +++ b/admin/MasterMirroring.html.md.erb @@ -6,9 +6,9 @@ There are two masters in a HAWQ cluster-- a primary master and a standby master. You deploy a backup or mirror of the master instance on a separate host machine from the primary master so that the cluster can tolerate a single host failure. A backup master or standby master serves as a warm standby if the primary master becomes non-operational. You create a standby master from the primary master while the primary is online. -The primary master continues to provide services to users while HAWQ takes a transactional snapshot of the primary master instance. While HAWQ takes transactional snapshot and deploys it to the standby master, HAWQ also records changes to the primary master. After HAWQ deploys the snapshot to the standby master, HAWQ deploys the updates to synchronize the standby master with the primary master. +The primary master continues to provide services to users while HAWQ takes a transactional snapshot of the primary master instance. In addition to taking a transactional snapshot and deploying it to the standby master, HAWQ also records changes to the primary master. After HAWQ deploys the snapshot to the standby master, HAWQ deploys the updates to synchronize the standby master with the primary master. -After the primary master and standby master are synchronized, HAWQ keeps the standby master up to date by walsender and walreceiver, which are write-ahead log (WAL)-based replication processes. The walreceiver is a standby master process. The walsender process is a primary master process. The two processes use WAL-based streaming replication to keep the primary and standby masters synchronized. +After the primary master and standby master are synchronized, HAWQ keeps the standby master up to date using walsender and walreceiver, write-ahead log (WAL)-based replication processes. The walreceiver is a standby master process. The walsender process is a primary master process. The two processes use WAL-based streaming replication to keep the primary and standby masters synchronized. Since the master does not house user data, only system catalog tables are synchronized between the primary and standby masters. When these tables are updated, changes are automatically copied to the standby master to keep it current with the primary. @@ -17,83 +17,89 @@ Since the master does not house user data, only system catalog tables are synchr  -If the primary master fails, the replication process stops, and an administrator can activate the standby master. Upon activation of the standby master, the replicated logs reconstruct the state of the primary master at the time of the last successfully committed transaction. The activated standby then functions as the HAWQ master, accepting connections on the port specified when standby master was initialized. +If the primary master fails, the replication process stops, and an administrator can activate the standby master. Upon activation of the standby master, the replicated logs reconstruct the state of the primary master at the time of the last successfully committed transaction. The activated standby then functions as the HAWQ master, accepting connections on the port specified when the standby master was initialized. -If the master fails, the administrator runs the hawq activate standby utility or uses Ambari to have the standby master take over as the new primary master. +If the master fails, the administrator uses command line tools or Ambari to instruct the standby master to take over as the new primary master. **Tip:** You can configure a virtual IP address for the master and standby so that client programs do not have to switch to a different network address when the âactiveâ master changes. If the master host fails, the virtual IP address can be swapped to the actual acting master. ##Configuring Master Mirroring <a id="standby_master_configure"></a> -You can configure a new HAWQ system with a standby master during HAWQâs installation process or you can add a standby master later using the hawq init standby command line utility. This topic assumes you are adding a standby master to an existing system. +You can configure a new HAWQ system with a standby master during HAWQâs installation process, or you can add a standby master later. This topic assumes you are adding a standby master to an existing node in your HAWQ cluster. -###To add a standby master to an existing system +###Add a standby master to an existing system -1. Ensure the host machine for the standby master has been installed with HAWQ and configured accordingly. - * gpadmin system user created - * HAWQ binaries are installed - * environment variables set - * SSH keys exchanged - * Data directory created -1. Run the `hawq init standby` utility on the host of the currently active primary master to add a standby master host to your HAWQ system. For example: +1. Ensure the host machine for the standby master has been installed with HAWQ and configured accordingly: + * The gpadmin system user has been created. + * HAWQ binaries are installed. + * HAWQ environment variables are set. + * SSH keys have been exchanged. + * HAWQ Master Data directory has been created. - ```shell - $ hawq init standby -s new_standby_master_hostname - ``` +2. Initialize the HAWQ master standby: + + a. If you use Ambari to manage your cluster, follow the instructions in [Adding a HAWQ Standby Master](ambari-admin.html#amb-add-standby). + + b. If you do not use Ambari, log in to the HAWQ master and re-initialize the HAWQ master standby node: + + ``` shell + $ ssh gpadmin@<hawq_master> + hawq_master$ . /usr/local/hawq/greenplum_path.sh + hawq_master$ hawq init standby -s <new_standby_master> + ``` - where `-s` specifies the hostname of the standby master. + where \<new\_standby\_master\> identifies the hostname of the standby master. -1. Then, check on the status of master mirroring by querying the `gp_master_mirroring system` view. See Checking on the State of Master Mirroring for instructions. +3. Check the status of master mirroring by querying the `gp_master_mirroring system` view. See [Checking on the State of Master Mirroring](#standby_check) for instructions. -1. To activate or failover to the standby master, see [Failing Over to a Standby Master](#standby_failover). +4. To activate or failover to the standby master, see [Failing Over to a Standby Master](#standby_failover). ##Failing Over to a Standby Master<a id="standby_failover"></a> -If the primary master fails, log replication stops. Use `hawq activate standby` to activate the standby master. +If the primary master fails, log replication stops. You must explicitly activate the standby master in this circumstance. Upon activation of the standby master, HAWQ reconstructs the state of the master at the time of the last successfully committed transaction. ###To activate the standby master -1. Ensure that a standby master host has been configured for the system. +1. Ensure that a standby master host has been configured for the system. -1. Run the hawq activate standby utility from the standby master host you are activating. For example: +2. Activate the standby master: - ```shell - $ hawq activate standby + a. If you use Ambari to manage your cluster, follow the instructions in [Activating the HAWQ Standby Master](ambari-admin.html#amb-activate-standby). + + b. If you do not use Ambari, log in to the HAWQ master and activate the HAWQ master standby node: + + ``` shell + hawq_master$ hawq activate standby ``` - -1. After you activate the standby master, it becomes the active or primary master for the HAWQ cluster. -1. (Optional, but recommended.) Configure a new standby master. Run the following command: + After you activate the standby master, it becomes the active or primary master for the HAWQ cluster. - ```shell - $ hawq init standby -s new_standby_master_hostname - ``` - where `-s` specifies the hostname of the standby master. +4. (Optional, but recommended.) Configure a new standby master. See [Add a standby master to an existing system](#standby_master_configure) for instructions. -1. Run hawq state to check the status of the cluster: +5. Check the status of the HAWQ cluster by executing the following command on the master: ```shell - $ hawq state + hawq_master$ hawq state ``` - The newly activated master's status should be **Active**. - -1. If you configured a new standby master, its status is **Passive**. When a standby master is not configured, the command displays `-No entries found` and the message indicates that a standby master instance is not configured. + The newly-activated master's status should be **Active**. If you configured a new standby master, its status is **Passive**. When a standby master is not configured, the command displays `-No entries found`, the message indicating that no standby master instance is configured. -1. Query the `gp_segment_configuration` table to verify that segments have registered themselves to the new master. +6. Query the `gp_segment_configuration` table to verify that segments have registered themselves to the new master: - $ psql dbname -c 'SELECT * FROM gp_segment_configuration;' + ``` shell + hawq_master$ psql dbname -c 'SELECT * FROM gp_segment_configuration;' + ``` -1. Then, check on the status of master mirroring by querying the `gp_master_mirroring` system view. See [Checking on the State of Master Mirroring](#standby_check) for instructions. +7. Finally, check the status of master mirroring by querying the `gp_master_mirroring` system view. See [Checking on the State of Master Mirroring](#standby_check) for instructions. ##Checking on the State of Master Mirroring <a id="standby_check"></a> -To check on the status of master mirroring, query the `gp_master_mirroring` system view. The view provides information about the walsender process used for HAWQ master mirroring. +To check on the status of master mirroring, query the `gp_master_mirroring` system view. This view provides information about the walsender process used for HAWQ master mirroring. ```shell -$ psql dbname -c 'SELECT * FROM gp_master_mirroring;' +hawq_master$ psql dbname -c 'SELECT * FROM gp_master_mirroring;' ``` If a standby master has not been set up for the cluster, you will see the following output: @@ -105,7 +111,7 @@ If a standby master has not been set up for the cluster, you will see the follow (1 row) ``` -If the standby is configured and in sync with the master, then you will see something similar to the following output: +If the standby is configured and in sync with the master, you will see output similar to the following: ``` summary_state | detail_state | log_time | error_message @@ -116,8 +122,7 @@ If the standby is configured and in sync with the master, then you will see some ##Resynchronizing Standby with the Master <a id="resync_master"></a> - -If the the log synchronization process between the master and standby has stopped or has fallen behind, then the standby can become out-of-date. If this occurs, you will see something similar to the following output after querying the `gp_master_mirroring` view. +The standby can become out-of-date if the log synchronization process between the master and standby has stopped or has fallen behind. If this occurs, you will observe output similar to the following after querying the `gp_master_mirroring` view: ``` summary_state | detail_state | log_time | error_message @@ -126,10 +131,14 @@ If the the log synchronization process between the master and standby has stoppe (1 row) ``` -To resynchronize the standby with the master, execute the following command on the master. +To resynchronize the standby with the master: -```shell -$ hawq init standby -n -``` +1. If you use Ambari to manage your cluster, follow the instructions in [Removing the HAWQ Standby Master](ambari-admin.html#amb-remove-standby). + +2. If you do not use Ambari, execute the following command on the HAWQ master: + + ```shell + hawq_master$ hawq init standby -n + ``` -This command stops and restarts the master and then synchronizes the standby. + This command stops and restarts the master and then synchronizes the standby.
