Привет !!!
Это касается определенного требования к rsync, которого мы пытаемся достичь. Мы пытались достичь этого, используя различные опции rsync. Однако мы сталкиваемся с различными проблемами с различными опциями rsync.
Предыстория: • У нас есть процесс (работающий на AIX), журналы которого регистрируются в A.log (присутствует в каталоге журналов). • A.log ротируется в A.CURRENT_DATE_TIME.log, как только он достигает 100 МБ, и создается новый A.log. • Мы передаем эти журналы на централизованный сервер с помощью rsync. Мы используем rsync для всего каталога журналов. • INODE файлов на исходном сервере и на целевом сервере различаются. • После того, как журналы находятся на централизованном сервере, идея состоит в том, чтобы заставить эти журналы читаться/индексироваться централизованным процессом журналирования, который будет выбирать входные данные с этого централизованного сервера.
Проблема: • Хотя A.log (сервер назначения) указан в качестве входных данных для централизованного процесса журнала, он учитывает INODE файла, а не фактическое имя файла. • Таким образом, когда файл A.log сворачивается, новый A.log имеет новый INODE, который не обнаруживается централизованным процессом. Это происходило, когда мы использовали опции -u –r –t с rsync. Таким образом, в этом случае INODE файла менялся каждый раз, когда происходил rsync, а также когда происходила смена. Следовательно, процесс останавливает индексацию, поскольку он ищет старый INODE, которого нет.
• Идея заключается в использовании rsync с комбинацией параметров, которые не изменят INODE файла во время rsync, но должны изменить INODE во время смены, когда A.log вращается в A.CURRENT_DATE_TIME.log. Поэтому, чтобы добиться этого, мы включили параметр –inplace, и мы можем сохранить INODE во время rsync и INODE изменяется во время смены файла. Однако теперь это дает нам другую проблему, когда имя файла не меняется и всегда остается A.log. Поэтому, как только процесс завершает индексацию A.log, он останавливается.
Было бы здорово, если бы кто-то мог предложить что-то, что могло бы помочь нам в достижении указанных требований.
С уважением, Пунит Синха Администратор промежуточного программного обеспечения
решение1
Я не рекомендую полагаться на inode. Он будет меняться каждый раз, когда файл перемещается с исходной машины на целевую. Он также изменится, если файлы будут восстановлены из резервных копий. Если система обработки журналов зависит от inode, то если вы когда-либо восстановитесь из резервных копий, система не будет работать так, как вы ожидали.
Я рекомендую НЕ копировать A.log, а только копировать A.CURRENT_DATE_TIME.log. Это упростит проект.
Я подозреваю, что система обработки журналов на целевом сервере просматривает inode, чтобы определить, является ли файл, который он ранее видел как A.log, теперь A.CURRENT_DATE_TIME.log. Это не будет надежным.
У вышеприведенного решения есть 1 проблема: время, необходимое для генерации строки в файле журнала до ее обработки централизованным процессом журнала, увеличится. Например, если A.log требуется 3 дня, чтобы вырасти до 100 МБ, то ничего из этого файла не попадет в централизованный процесс журнала в течение 3 дней. Если журналы нельзя задержать более чем на 2 часа, то я бы ротировал журналы каждый час. Таким образом, вы будете знать, что находитесь в пределах 2-часовой цели.