Backup_log_dir_for_component_Dgraph2 не удалось выполнить базовое обновление. Ошибка отказа в доступе в журнале Dgraph

Во время базового обновления я получаю сообщение об ошибке, поскольку сбой backup_log_dir_for_component_Dgraph2.

1. Ниже приведена ошибка из файла baseline_update.out.

            Setting flag 'baseline_data_ready' in the EAC.
                1 file(s) moved.
        [06.28.16 05:26:02] INFO: Checking definition from AppConfig.xml against existing EAC provisioning.
        [06.28.16 05:26:02] INFO: Definition has not changed.
        [06.28.16 05:26:02] INFO: Starting baseline update script.
        [06.28.16 05:26:02] INFO: Acquired lock 'update_lock'.
.
.
.
more logs in between
.
.
.
        [06.28.16 05:26:17] INFO: [ITLHost] Starting component 'Forge'.
        [06.28.16 05:45:14] INFO: [ITLHost] Starting backup utility 'backup_log_dir_for_component_Dgidx'.
        [06.28.16 05:45:15] INFO: [ITLHost] Starting component 'Dgidx'.
        [06.28.16 06:00:59] INFO: [MDEXHost] Starting shell utility 'cleanDir_local-dgraph-input'.
        [06.28.16 06:01:01] INFO: [MDEXHost] Starting shell utility 'rmdir_dgraph-input-old'.
        [06.28.16 06:01:03] INFO: [MDEXHost] Starting copy utility 'copy_index_to_host_MDEXHost'.
        [06.28.16 06:01:26] INFO: Applying index to dgraphs in restart group 'A'.
        [06.28.16 06:01:26] INFO: [MDEXHost] Starting shell utility 'mkpath_dgraph-input-new'.
        [06.28.16 06:01:27] INFO: [MDEXHost] Starting copy utility 'copy_index_to_temp_new_dgraph_input_dir_for_Dgraph1'.
        [06.28.16 06:01:59] INFO: [MDEXHost] Starting shell utility 'move_dgraph-input_to_dgraph-input-old'.
        [06.28.16 06:02:01] INFO: [MDEXHost] Starting shell utility 'move_dgraph-input-new_to_dgraph-input'.
        [06.28.16 06:02:02] INFO: [MDEXHost] Starting backup utility 'backup_log_dir_for_component_Dgraph1'.
        [06.28.16 06:02:03] INFO: [MDEXHost] Starting component 'Dgraph1'.
        [06.28.16 06:02:10] INFO: [MDEXHost] Starting shell utility 'rmdir_dgraph-input-old'.
        [06.28.16 06:02:12] INFO: Applying index to dgraphs in restart group 'B'.
        [06.28.16 06:02:12] INFO: [MDEXHost] Starting shell utility 'mkpath_dgraph-input-new'.
        [06.28.16 06:02:13] INFO: [MDEXHost] Starting copy utility 'copy_index_to_temp_new_dgraph_input_dir_for_Dgraph2'.
        [06.28.16 06:02:38] INFO: Stopping component 'Dgraph2'.
        [06.28.16 06:02:39] INFO: [MDEXHost] Starting shell utility 'move_dgraph-input_to_dgraph-input-old'.
        [06.28.16 06:02:40] INFO: [MDEXHost] Starting shell utility 'move_dgraph-input-new_to_dgraph-input'.
        [06.28.16 06:02:42]

     INFO: [MDEXHost] Starting backup utility 'backup_log_dir_for_component_Dgraph2'.
        [06.28.16 06:02:43] SEVERE: Utility 'backup_log_dir_for_component_Dgraph2' failed. Refer to utility logs in [ENDECA_CONF]/logs/archive on host MDEXHost.
        Occurred while executing line 5 of valid BeanShell script:
        [[
        2|      
        3|    DgraphCluster.cleanDirs();
        4|    DgraphCluster.copyIndexToDgraphServers();
        5|    DgraphCluster.applyIndex();
        6|     
        7|   
        ]]

        [06.28.16 06:02:43] SEVERE: Error executing valid BeanShell script.
        Occurred while executing line 35 of valid BeanShell script:
        [[
        32|        Dgidx.run();
        33|       
        34|        // distributed index, update Dgraphs
        35|        DistributeIndexAndApply.run();
        36|
        37|        // if Web Studio is integrated, update Web Studio with latest
        38|        // dimension values
        ]]

        [06.28.16 06:02:43] SEVERE: Caught an exception while invoking method 'run' on object 'BaselineUpdate'. Releasing locks.

2. Ниже приведена ошибка из файла backup_log_dir_for_component_Dgraph2.log (Путь к файлу PlatformServices\workspace\logs\archive)

Renaming G:\Endeca\MyEndecaApp\config\script\..\..\.\logs\dgraphs\Dgraph2 to G:\Endeca\MyEndecaApp\config\script\..\..\.\logs\dgraphs\Dgraph2.2016_06_28.06_02_42
Unable to rename G:\Endeca\MyEndecaApp\config\script\..\..\.\logs\dgraphs\Dgraph2 to G:\Endeca\MyEndecaApp\config\script\..\..\.\logs\dgraphs\Dgraph2.2016_06_28.06_02_42: Permission denied

Я пытался запускать базовое обновление снова и снова, иногда Dgraph1 терпит неудачу, а иногда Dgraph2. После сбоя dgraph также остановился.

Изменить 1: я заметил, что когда я останавливаю оба dgraphs из рабочей среды, а затем запускаю базовое обновление, оно всегда выполняется успешно. Я пробовал это 4-5 раз. Мы знаем, что baseline_update останавливает dgraph перед резервным копированием папки журнала. Поэтому я предполагаю, что dgraph не остановлен должным образом до того, как baseline_update сделает резервную копию папки журнала, и поэтому он генерирует ошибку.

Пожалуйста, помогите мне в решении проблемы. Я новичок в администрации Endeca

Спасибо


endeca
person Himalaya Garg    schedule 28.06.2016    source источник
comment
Разве это не просто проблема с правами пользователя? Я заметил, что во втором файле журнала есть Permission Denied.   -  person bated    schedule 28.06.2016
comment
Нет, права пользователя уже проверены, это не проблема с разрешениями, потому что компоненты Endeca Forge, Dgidx, Dgraph1 успешно запустились и смогли переименовать папки журналов. Выдает ошибку в Dgraph2. Также, как я уже сказал, иногда Dgraph1 дает сбой, а иногда Dgraph2.   -  person Himalaya Garg    schedule 29.06.2016

Ответы (3)


arrow_upward
2
arrow_downward

Есть несколько сценариев, которые вызовут проблемы с разрешениями.

Согласно документации по установке Endeca, вы должны установить Endeca как определенный пользователь на сервере Windows. Предположим, что пользователя зовут 'endeca'. Убедились ли вы, что пользователь endeca является текущим владельцем папки G:\Endeca\MyEndecaApp и подпапок? После указания «владельца» вам также необходимо установить права доступа к этой папке как Full для пользователя «endeca». Вы запускаете службы Endeca как пользователь endeca?

Предполагая, что вы сделали все вышеперечисленное и у вас все еще есть проблема, это также может произойти в зависимости от того, как вы запускаете свой индекс. Если вы запускаете базовый индекс из командной строки CMD, делаете ли вы это от имени себя, пользователя «endeca» или «Администратора»? В зависимости от того, кто запускал последний индекс, будет определяться, есть ли у вас разрешение на все последующие запуски. Я склонен выполнять строки CMD как «Администратор», и у меня было очень мало проблем с разрешениями.

Возможно, вы проверяете файлы журнала в «Notepad.exe»? Он агрессивно блокирует файл, поэтому вы не сможете переименовать файл или папку, если она открыта в «Блокноте». Либо убедитесь, что он не открыт в «Блокноте», либо используйте «Блокнот++», который не блокирует файл.

Наконец, у меня также были проблемы, когда приглашение CMD было открыто в папке журнала, которую необходимо переименовать. Поэтому убедитесь, что приглашение CMD либо закрыто, либо не открывает папки журнала.

Последние 3 года я запускал Endeca на Windows Server 2012 R2, и это единственные проблемы, с которыми я сталкивался. Если ничего не помогает, вы всегда можете попробовать инструменты sysinternals, в частности procmon.exe, но он выведет много информации во время создания индекса, поэтому будьте готовы к информационной перегрузке.

person radimpe    schedule 29.06.2016
comment
Спасибо за ваш ответ. У нас есть пользователь endeca с полными правами на папку G:\Endeca\MyEndecaApp и все подпапки. Также я запускаю базовый уровень с помощью «Администратора». Я не открываю ни один файл, когда работает базовая линия. На самом деле ошибка в Baseline прерывистая, иногда она запускается, а в следующий раз выходит из строя. Но когда я вручную останавливаю оба dgraph из рабочей среды, а затем запускаю базовый уровень, он всегда завершается успешно. Означает ли это, что когда baseline останавливает Dgraph во время его выполнения, останавливается задержка dgraph и происходит сбой папки журнала переименования? Можем ли мы что-нибудь сделать, если это так? - person Himalaya Garg; 01.07.2016

arrow_upward
1
arrow_downward

Изменение свойства Dgraph 'numIdleSecondsAfterStop' на 90 секунд из рабочей среды IAP решило проблему.

Это показывает, что сбой произошел из-за того, что Dgraph не был должным образом остановлен до переименования и блокировки папки журнала Dgraph.

Параметр 'numIdleSecondsAfterStop' заставляет базовый план ожидать обработки следующих шагов в течение 90 секунд после остановки Dgraph.

person Himalaya Garg    schedule 05.07.2016

arrow_upward
0
arrow_downward

Проблема очень хорошо видна в журналах, такой папки не существует, поэтому базовый процесс не может переименовать папку Dgraph2. Обычно это происходит, когда происходит сбой процесса между выполнением базового обновления. Скажем, например, вы запустили процесс, и сценарий очищает папку после резервного копирования этого содержимого, и это не удается. Опять же, вы можете запустить процесс с первого раза, поэтому, когда он снова попытается очистить то же самое, вы обычно получите ошибку отсутствия папки. Простое решение заключается в том, чтобы создать отсутствующую папку Dgraph2 или в случае сбоя обновления из-за сбоя рабочей среды или чего-то еще. Затем прокомментируйте сценарий конфигурации приложения, пока он не будет успешно запущен, и снова запустите его из этого конкретного экземпляра. Надеюсь это поможет!

person Bananas    schedule 27.06.2017