인사말 !!!
이는 우리가 달성하려는 rsync에 대한 특정 요구 사항에 관한 것입니다. 우리는 다양한 rsync 옵션을 사용하여 이를 달성하려고 노력했습니다. 그러나 다양한 rsync 옵션으로 인해 다양한 문제가 발생합니다.
배경: • A.log(logs 디렉터리에 있음)에 기록되는 프로세스(AIX에서 실행) 로그가 있습니다. • A.log는 100MB에 도달하고 새 A.log가 생성되면 A.CURRENT_DATE_TIME.log로 교체됩니다. • rsync를 사용하여 이러한 로그를 중앙 집중식 서버로 전송하고 있습니다. 전체 로그 디렉터리에서 rsync를 사용하고 있습니다. • 원본 서버와 대상 서버에 있는 파일의 INODE가 다릅니다. • 로그가 중앙 집중식 서버에 있으면 중앙 집중식 서버에서 입력을 선택하는 중앙 집중식 로그 프로세스를 통해 이러한 로그를 읽고 색인화하는 것이 아이디어입니다.
문제: • A.log(대상 서버)가 중앙 로그 프로세스에 대한 입력으로 제공되지만 실제 파일 이름이 아닌 파일의 INODE를 고려합니다. • 따라서 A.log 파일이 롤오버되면 새 A.log에는 중앙 집중식 프로세스에서 감지되지 않는 새 INODE가 있습니다. 이것은 rsync와 함께 -u –r –t 옵션을 사용할 때 발생했습니다. 따라서 이 경우 rsync가 발생할 때마다 그리고 롤오버가 발생할 때마다 파일의 INODE가 변경되었습니다. 따라서 프로세스는 존재하지 않는 이전 INODE를 찾기 때문에 인덱싱을 중지합니다.
• 아이디어는 rsync 시 파일의 INODE를 변경하지 않지만 A.log가 A.CURRENT_DATE_TIME.log로 회전할 때 롤오버 시 INODE를 변경해야 하는 옵션 조합과 함께 rsync를 사용하는 것입니다. 따라서 이를 달성하기 위해 –inplace 옵션을 포함시켰으며 파일 회전 시 rsync 및 INODE 변경 시 INODE를 유지할 수 있습니다. 그러나 이제 파일 이름이 변경되지 않고 항상 A.log로 유지되는 또 다른 문제가 발생합니다. 따라서 프로세스가 A.log 인덱싱을 완료하면 중지됩니다.
언급된 요구 사항을 달성하는 데 도움이 될 수 있는 내용을 누군가가 제안할 수 있다면 좋을 것입니다.
감사합니다. Puneet Sinha 미들웨어 관리자
답변1
나는 inode에 의존하는 것을 권장하지 않습니다. 파일이 원본에서 대상 컴퓨터로 이동할 때마다 변경됩니다. 파일이 백업에서 복원되는 경우에도 변경됩니다. 로그 처리 시스템이 inode에 의존하는 경우 백업에서 복원하면 시스템이 예상대로 작동하지 않습니다.
내 권장 사항은 A.log를 복사하지 않고 A.CURRENT_DATE_TIME.log만 복사하는 것입니다. 이렇게 하면 프로젝트가 단순화됩니다.
대상 서버의 로그 처리 시스템이 이전에 A.log로 표시되었던 파일이 이제 A.CURRENT_DATE_TIME.log인지 확인하기 위해 inode를 조사하고 있는 것으로 의심됩니다. 그것은 신뢰할 수 없을 것입니다.
위의 해결 방법에는 한 가지 문제가 있습니다. 중앙 집중식 로그 프로세스에서 로그 파일을 처리할 때 로그 파일의 한 줄이 생성되는 데 걸리는 시간이 늘어납니다. 예를 들어 A.log가 100MB로 커지는 데 3일이 걸리는 경우 해당 파일의 어떤 것도 최대 3일 동안 중앙 집중식 로그 프로세스에 입력되지 않습니다. 로그를 2시간 이상 지연할 수 없으면 1시간마다 로그를 교체합니다. 그렇게 하면 2시간 목표 내에 있다는 것을 알 수 있습니다.