CDH4 Восстановление Cloudera Manager в существующем кластере

Наш производственный узел Cloudera Manager (4.7) вышел из строя, поэтому мы установили на этот узел новую ОС. Мы пытаемся восстановить Cloudera Manager из имеющихся у нас резервных копий (встроенной) базы данных postgresql. Мы надеемся, что с помощью восстановленной БД CM сможет управлять существующим кластером с существующими конфигурациями.

Мы делаем несколько POC, в которых пытаемся перенести менеджер cloudera на новый сервер с помощью шагов, описанных ниже. (В конце концов мы установим CM на тот же узел)

  1. установить cloudera-server-daemons cloudera-server
  2. установить cloudera-server-db
  3. sudo service cloudera-server-db start => создает базовые роли; восстанавливает пароли и т. д.
  4. поэтому из нашего pg_dumpall foo.sql мы удалили начальные операторы, создающие роли, пароли и базу данных. pql -U cloudera-scm -h localhost -p 7432 -f foo.sql postgres .Это успешно завершено.
  5. На каждом узле в кластере измените файл /etc/cloudera-scm-agent/config.ini, чтобы он указывал на новый узел.
  6. запуск службы sudo cloudera-server. => мы ожидали, что CM подберет конфиги и просто загрузит. Однако это приводит нас к странице установки
  7. Установите бесплатную версию. Либо ищем ips либо видим доступные хосты.
  8. Затем он обновляет пакеты cdh на каждом узле в кластере и запрашивает установку служб.
  9. После этого процесс немного неясен. Однако нам удалось назначить роли соответствующим узлам, например. HDFS с использованием того же корневого каталога не был отформатирован, и все в порядке. Однако вся наша конфигурация отсутствует. Кажется, это говорит о том, что CM не считывал восстановленную БД.

Вышеуказанные шаги не кажутся правильным способом восстановления состояния менеджера облака. Это Reference, возможно, содержит простой способ сделать это. Следуя шагам, упомянутым в ссылке, мы все еще не можем заставить CM считать восстановленную БД. Может кто-нибудь указать правильные шаги, пожалуйста? Любая помощь приветствуется.


person sunny    schedule 14.02.2015    source источник


Ответы (1)


После множества проверок мы пришли к выводу, что дамп БД бесполезен. К счастью для нас, у нас был каталог /data для файла postgresql.

Мы выбрали ту же машину для переустановки (поэтому не нужно возиться с именами хостов и IP-адресами в /etc/cloudera-scm-agent/config.ini). Поэтому мы установили правильную версию postgresql, cloudera-scm-server, cloudera-scm-server-db, cloudera-scm-agent, cloudera-scm-daemons и связанные с ними зависимости.

Одна проблема, с которой мы столкнулись, заключалась в том, что мы потеряли файл db.mgmt.properties. Мы смогли изменить пароли пользователей (amon, hmon, smon, nav и т. д.). Логика пароля — md5(yourPasswordUser) с использованием функции md5, доступной в postgres. Кроме того, вам нужно добавить к этому паролю «md5».

Загрузите cloudera-scm-server, и все службы появятся. Если есть проблемы с подключением к базе данных, перейдите к соответствующей службе, например. отслеживайте активность и меняйте пароль на yourPassword. начать сначала.

Это сработало для нас. Нам не нужно было устанавливать или перенастраивать сервисы.

person sunny    schedule 18.02.2015