hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerry He (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-8565) stop-hbase.sh clean up: backup master
Date Fri, 02 Aug 2013 19:07:52 GMT

     [ https://issues.apache.org/jira/browse/HBASE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jerry He updated HBASE-8565:
----------------------------

    Description: 
In stop-hbase.sh:
{code}
  # TODO: store backup masters in ZooKeeper and have the primary send them a shutdown message
  # stop any backup masters
  "$bin"/hbase-daemons.sh --config "${HBASE_CONF_DIR}" \
    --hosts "${HBASE_BACKUP_MASTERS}" stop master-backup
{code}

After HBASE-5213, stop-hbase.sh -> hbase master stop will bring down the backup master
too via the cluster status znode.

We should not need the above code anymore.

Another issue happens when the current master died and the backup master became the active
master.
{code}
nohup nice -n ${HBASE_NICENESS:-0} "$HBASE_HOME"/bin/hbase \
   --config "${HBASE_CONF_DIR}" \
   master stop "$@" > "$logout" 2>&1 < /dev/null &

waitForProcessEnd `cat $pid` 'stop-master-command'
{code}
We can still issue 'hbase-stop.sh' from the old master.
stop-hbase.sh -> hbase master stop -> look for active master -> request shutdown
This process still works.
But the waitForProcessEnd statement will not work since the local master pid is not relevant
anymore.
What is the best way in the this case?


  was:
In stop-hbase.sh:
{code}
  # TODO: store backup masters in ZooKeeper and have the primary send them a shutdown message
  # stop any backup masters
  "$bin"/hbase-daemons.sh --config "${HBASE_CONF_DIR}" \
    --hosts "${HBASE_BACKUP_MASTERS}" stop master-backup
{code}

After HBASE-5213, stop-hbase.sh -> hbase master stop will bring up the backup master too
via the cluster status znode.

We should not need the above code anymore.

Another issue happens when the current master died and the backup master became the active
master.
{code}
nohup nice -n ${HBASE_NICENESS:-0} "$HBASE_HOME"/bin/hbase \
   --config "${HBASE_CONF_DIR}" \
   master stop "$@" > "$logout" 2>&1 < /dev/null &

waitForProcessEnd `cat $pid` 'stop-master-command'
{code}
We can still issue 'hbase-stop.sh' from the old master.
stop-hbase.sh -> hbase master stop -> look for active master -> request shutdown
This process still works.
But the waitForProcessEnd statement will not work since the local master pid is not relevant
anymore.
What is the best way in the this case?


    
> stop-hbase.sh clean up: backup master
> -------------------------------------
>
>                 Key: HBASE-8565
>                 URL: https://issues.apache.org/jira/browse/HBASE-8565
>             Project: HBase
>          Issue Type: Bug
>          Components: master, scripts
>    Affects Versions: 0.94.7, 0.95.0
>            Reporter: Jerry He
>            Priority: Minor
>             Fix For: 0.98.0, 0.95.2, 0.94.12
>
>
> In stop-hbase.sh:
> {code}
>   # TODO: store backup masters in ZooKeeper and have the primary send them a shutdown
message
>   # stop any backup masters
>   "$bin"/hbase-daemons.sh --config "${HBASE_CONF_DIR}" \
>     --hosts "${HBASE_BACKUP_MASTERS}" stop master-backup
> {code}
> After HBASE-5213, stop-hbase.sh -> hbase master stop will bring down the backup master
too via the cluster status znode.
> We should not need the above code anymore.
> Another issue happens when the current master died and the backup master became the active
master.
> {code}
> nohup nice -n ${HBASE_NICENESS:-0} "$HBASE_HOME"/bin/hbase \
>    --config "${HBASE_CONF_DIR}" \
>    master stop "$@" > "$logout" 2>&1 < /dev/null &
> waitForProcessEnd `cat $pid` 'stop-master-command'
> {code}
> We can still issue 'hbase-stop.sh' from the old master.
> stop-hbase.sh -> hbase master stop -> look for active master -> request shutdown
> This process still works.
> But the waitForProcessEnd statement will not work since the local master pid is not relevant
anymore.
> What is the best way in the this case?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message