目录

简介

故障排除

会话管理器实例恢复过程

从关闭状态打开会话管理器电源

从错误状态恢复任何实例

会话管理器/MongoDB恢复

处于脱机状态的复制副本集的成员

复本集的成员停滞在“启动”状态2/恢复状态长时间

重建复制副本集

从备份后副本集恢复数据库

简介

本文档介绍在Ultra-M/OpenStack部署上部署的会话管理器恢复过程。

故障排除

会话管理器实例恢复过程

从关闭状态打开会话管理器电源

如果任何实例由于计划的关闭或其他原因处于SHUTOFF状态，请使用此过程启动实例并在ESC中启用itâ€™s监控。

1. 通过OpenStack检查实例的状态

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep sm-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | SHUTOFF|

2. 检查计算是否可用，并确保状态为up。

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

3. 以管理员用户身份登录到弹性服务控制器(ESC)Master并检查opdata中实例的状态。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. 从openstack打开实例电源

source /home/stack/destackovsrc-Pcrf

nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
。

5. 等待5分钟，使实例启动并进入活动状态。

source /home/stack/destackovsrc-Pcrf

nova list –fields name,status | grep sm-s1_0

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. 在实例处于活动状态后，在ESC中启用VM监控。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

有关实例配置的进一步恢复，请参阅下一节中提供的实例类型特定过程。

从错误状态恢复任何实例

如果openstack中CPS实例的状态为ERROR，则可使用此过程：

1. 检查OpenStack中实例的状态。

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep sm-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | ERROR|

2. 检查计算是否可用并运行正常。

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep â€˜status|stateâ€™

| state                     | up                                       |

| status                    | enabled                                  |

3. 以管理员用户身份登录ESC Master并检查opdata中实例的状态。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. 重置实例状态以强制实例返回活动状态而不是错误状态，完成后，请重新启动实例。

source /home/stack/destackovsrc-Pcrf

nova reset-state â€“active SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

nova reboot â€“-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

5. 等待5分钟，使实例启动并进入活动状态。

source /home/stack/destackovsrc-Pcrf

nova list â€“fields name,status | grep sm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. 如果，集群管理器在重新启动后将状态更改为ACTIVE，则在集群管理器实例处于活动状态后在ESC中启用VM监控器。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

恢复到运行/活动状态后，请参阅实例类型特定过程以从备份恢复配置/数据。

会话管理器/MongoDB恢复

会话管理器在本节中为集群策略套件提供数据库层，讨论最近恢复的会话管理器实例上的数据库恢复：

处于脱机状态的复制副本集的成员

如果复制副本集的成员处于脱机状态，请使用以下过程：

1. 在群集管理器上使用此命令检查复制副本集的状态。

diagnostics.sh --get_replica_status

2. 在所有副本集中列出所有离线成员。

3. 在集群管理器上运行命令。

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

4. 安全外壳到会话管理器VM并启动监控进程。

ssh sessionmgrXX

/etc/init.d/sessionmgr-XXXXX start

复本集的成员停滞在“启动”状态2/恢复状态长时间

如果复制副本集的成员停滞在启动2或恢复状态，并且主成员在复制副本集中可用，请使用以下过程：

1. 在群集管理器上使用此命令检查复制副本集的状态。

diagnostics.sh --get_replica_status

2. 列出所有复制集中的所有成员。

3. 安全外壳到sessionmgr VM并获取mongo进程的存储位置。如示例dbpath所示，在端口37717的sessionmgr01上运行的mongo进程为/var/data/sessions.1/b。

ssh sessionmgr01

ps -ef | grep mongo | grep 37717

root      2572     1 25 Feb11 ?        24-11:43:43 /usr/bin/mongod --ipv6 --nojournal --storageEngine mmapv1 --noprealloc --smallfiles --port 37717 --dbpath=/var/data/sessions.1/b --replSet set01b --fork --pidfilepath /var/run/sessionmgr-37717.pid --oplogSize 5120 --logpath /var/log/mongodb-37717.log --logappend --quiet --slowms 500

4. 停止mongo进程并清除dbpath中的内容：

/etc/init.d/sessionmgr-xxxxx stop

rm -rf /var/data/sessions.1/b/*

5. 启动mongo进程，这会导致复制副本集成员同步来自主数据库的所有数据，而不是操作日志。

/etc/init.d/sessionmgr-xxxxx start

第5步可能需要相当长的时间才能同步来自主数据库的所有数据，具体取决于数据库大小。

重建复制副本集

由于某些中断，可能需要重建部分或所有复制副本集。但是，在决定重建部分或全部复制副本集之前，可能会注意到这些复制副本集中的所有数据都可能丢失。必须交叉验证这些数据库的备份可用性：

- 管理员(通常为27721)

- 余额(通常在端口27718上)

- SPR(通常在端口27720上)

在对备份进行交叉验证并做出重新创建数据库副本集的决策后，请使用以下过程：

1. 检查/etc/broadhop/mongoConfig.cfg的内容,LLD必须包含有关此文件中必须存在的配置的信息，或者您可以使用备份的文件。

2. 命令build_set.sh —<db-name> —create必须在集群管理器上运行，这取决于要重建的数据库。它会创建与该数据库相关的所有复制副本集。

注意：用于在复制副本集中创建所有dbs的命令可清除数据库。复制集的所有内容都将丢失。

3. 如果要为一个数据库重建特定的复制副本集，请使用以下命令：

build_set.sh --

--create --setname

4. 如果要重建所有数据库的所有复制副本集，请使用以下命令：

build_set.sh --all --create

从备份后副本集恢复数据库

一旦复制副本集的所有成员都联机并且其中一个成员是主成员，则可以通过此过程从备份中恢复mongoDB。

1. 要从备份恢复所有数据库，请使用以下命令：

config_br.py --action import --mongo-all  /mnt/backup/

2. 要通过config_br.py从备份恢复特定数据库，以下选项可用：

- SPR

config_br.py --action import --mongo-all --spr /mnt/backup/

- 管理员

config_br.py --action import  --mongo-all --admin  /mnt/backup/

- 余额

config_br.py --action import  --mongo-all --balance  /mnt/backup/

- 报告

config_br.py --action import  --mongo-all --report  /mnt/backup/

如果mongodump用于备份数据库，则说明它通过mongo恢复的使用：

1. 提取备份tar.gz文件。

tar -zxf /mnt/backup/

2. 找到包含要恢复的数据库的mongo转储的文件夹，然后更改目录以输入该文件夹。

ls -ltr  /mnt/backup/cd /mnt/backup/27721_backup_$(date +\%Y-\%m-\%d)/dump

3. 从备份恢复复制副本集。

mongorestore --host

--port

4. 或者，要恢复特定集合或数据库，请使用以下命令：

mongorestore --host

--port

--db

--