Приветствую !!!
Это касается конкретного требования к 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 завершен, он останавливается.
Было бы здорово, если бы кто-нибудь мог предложить что-то, что могло бы помочь нам в достижении указанных требований.
С уважением, Администратор промежуточного программного обеспечения Puneet Sinha
Я не рекомендую полагаться на индексный дескриптор. Он будет изменяться каждый раз, когда файл перемещается с исходного компьютера на целевой. Это также изменится, если файлы будут восстановлены из резервных копий. Если система обработки журналов зависит от индексного дескриптора, то при восстановлении из резервных копий система не будет работать должным образом.
Я рекомендую НЕ копировать A.log, а копировать только A.CURRENT_DATE_TIME.log. Это упростит проект.
Я подозреваю, что система обработки журналов на целевом сервере смотрит на индексный дескриптор, чтобы определить, является ли файл, который раньше видел как A.log, A.CURRENT_DATE_TIME.log. Это ненадежно.
Приведенное выше решение имеет одну проблему: время, необходимое для создания строки в файле журнала до момента ее обработки централизованным процессом журнала, увеличится. Например, если A.log вырастет до 100 МБ за 3 дня, то ничто из этого файла не войдет в процесс централизованного журнала на срок до 3 дней. Если журналы не могут быть отложены более чем на 2 часа, то я буду менять журналы каждые 1 час. Таким образом, вы будете знать, что находитесь в пределах 2-часовой цели.