ownCloud 파일 잠금 "잠금 메커니즘 시간 초과" 오류 해결 방법

ownCloud에서 동기화, 업로드, 이동, 이름 변경 또는 청크 조합 중에 파일 잠금 시간 초과 오류가 발생하는 경우, 가장 먼저 알아야 할 것은 해당 오류가 일반적으로 사용자에게 표시되는 수동 파일 잠금 기능이 아닌 트랜잭션 파일 잠금 과 관련이 있다는 점입니다. 트랜잭션 잠금은 두 요청이 동시에 동일한 파일을 저장하거나 변경하는 것을 방지하는 내부 안전 장치입니다. ownCloud에서는 기본적으로 활성화되어 있으며 데이터베이스 또는 Redis를 잠금 백엔드로 사용할 수 있습니다.

현재 ownCloud 11 문서에서는 데이터베이스 기반 잠금이 데이터베이스에 상당한 부하를 발생시키기 때문에 트랜잭션 파일 잠금에 Redis를 사용할 것을 권장합니다. 클러스터 설치 환경에서는 모든 애플리케이션 노드가 잠금을 위해 동일한 공유 Redis 인스턴스를 사용해야 합니다. 타임아웃 값을 변경하거나 잠금 레코드를 삭제하기 전에 이해해야 할 근본적인 해결책은 바로 이 부분입니다.

이 가이드는 초보 관리자의 관점에서 문제 해결 과정을 단계별로 설명합니다. 잠금의 의미, 백업해야 할 데이터, 오류 발생 구성 요소 확인 방법, Redis 구성 방법, 클러스터 구성이 상황에 미치는 영향, 그리고 문제를 악화시킬 수 있는 지름길에 대해 다룹니다.

오류가 의미하는 바는 무엇인가요?

ownCloud에서 파일을 변경하면 다른 요청이 동시에 호환되지 않는 변경 작업을 수행하지 못하도록 잠금을 획득합니다. 이 잠금은 상위 디렉터리에도 적용될 수 있으므로 해당 디렉터리 내에서 작업이 진행되는 동안에는 이름 변경이 불가능합니다. 잠금을 제때 획득하지 못하면 파일 손상 위험을 감수하는 대신 잠금 리소스 오류 또는 시간 초과 오류와 같은 오류와 함께 작업이 실패할 수 있습니다.

ownCloud 11 트랜잭션 파일 잠금 문서 에 따르면 이 메커니즘은 중단된 업로드, 공유 파일, 외부 저장소 및 암호화된 파일도 처리합니다.

이는 사용자가 웹 인터페이스에서 파일을 의도적으로 잠글 수 있도록 하는 선택적 WebDAV 기반 체크인/체크아웃 기능인 수동 파일 잠금 과는 다릅니다 . 수동 잠금은 사용자가 설정할 수 있는 만료 값을 제공합니다. 하지만 이러한 값을 변경해도 과부하가 걸렸거나 잘못 구성된 트랜잭션 잠금 백엔드 문제는 해결되지 않습니다.

시작하기 전에

• ownCloud 데이터베이스를 백업하고 config/config.php.
• 사용 중인 ownCloud 버전과 배포 유형(기존 패키지, Docker Compose 또는 멀티노드 클러스터)을 기록해 주세요.
• 사용 중인 데이터베이스 엔진과 Redis가 이미 설치되어 있는지 여부를 확인하십시오.
• 데스크톱 동기화, WebDAV 업로드, 폴더 이름 변경 또는 분할 업로드와 같이 실패한 정확한 작업을 기록하십시오.
• 문제가 특정 파일, 특정 사용자 또는 여러 사용자에게 동시에 영향을 미치는지 여부를 기록하십시오.

많은 사용자에게 영향을 미치는 광범위한 장애는 일반적으로 잠금 백엔드, 데이터베이스, Redis 또는 스토리지와 같은 공유 구성 요소와 관련이 있습니다. 특정 파일에서 반복적으로 발생하는 오류는 실제로 활성 작업이나 아직 만료되지 않은 오래된 잠금과 관련이 있을 수 있습니다.

1단계: 어떤 잠금 장치가 고장 났는지 확인합니다.

ownCloud 로그, 웹 서버 로그, PHP-FPM 로그 및 Redis 서비스 상태를 확인하세요. 반복적으로 발생하는 리소스 잠금 예외, 데이터베이스 잠금 대기 오류, Redis 연결 실패 또는 최초 작업이 완료된 후에도 동일한 경로가 오랫동안 차단된 상태로 남아 있는 패턴을 찾아야 합니다.

리눅스 호스트에서 유용한 점검 사항은 다음과 같습니다.

systemctl status redis-server
redis-cli PING
ps -ef | grep php
tail -n 200 /path/to/owncloud/data/owncloud.log

정상적인 Redis 명령은 를 반환해야 합니다 PONG. ownCloud가 소켓, 컨테이너 호스트 이름, 암호 또는 원격 호스트를 통해 Redis에 액세스하도록 구성된 경우 로컬 redis-cli테스트가 애플리케이션 연결을 입증한다고 가정하지 말고 ownCloud가 실제로 사용하는 동일한 연결 경로를 테스트하십시오.

로그에 "잠금 대기 시간 초과"와 유사한 데이터베이스 메시지가 포함되어 있으면 데이터베이스 경합 문제도 조사해야 합니다. 기존 데이터베이스 잠금 백엔드는 작동은 하지만 ownCloud 설명서에는 해당 백엔드가 데이터베이스에 상당한 부하를 발생시킨다고 명시적으로 경고하고 있습니다.

2단계: 트랜잭션 파일 잠금 기능을 Redis로 이전

기존 ownCloud 설치의 경우, Redis를 memcache.locking백엔드 로 구성하십시오 config/config.php. 현재 ownCloud 메모리 캐싱 문서에는 다음과 유사한 Redis TCP 예제가 제공됩니다.

'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 0,
    'password' => '',
],

빈 암호를 인터넷에 노출된 Redis 설정에 그대로 복사하지 마십시오. ownCloud 메모리 캐싱 문서에서는 Redis를 적절하게 보호할 것을 권장합니다. 이상적으로는 Redis는 신뢰할 수 있는 ownCloud 호스트 또는 내부 컨테이너 네트워크에서만 접근할 수 있어야 합니다.

ownCloud 공식 Docker 구성에서는 환경 변수를 사용하여 Redis를 활성화합니다. 현재 ownCloud 11 문서에는 다음과 같이 나와 있습니다.

OWNCLOUD_REDIS_ENABLED=true
OWNCLOUD_REDIS_HOST=redis
OWNCLOUD_REDIS_PORT=6379

해당 배포 모델에서 Redis가 활성화된 경우 ownCloud는 분산 캐시와 잠금 캐시를 모두 Redis로 자동으로 설정합니다. Docker 환경 변수와 수동으로 관리하는 설정을 혼합해서 사용하는 대신, config.php어떤 설정이 우선시되는지 명확히 이해하지 못하는 경우에는 설치에 대한 배포별 구성 문서를 참조하십시오.

3단계: 클러스터에서 모든 노드가 동일한 Redis를 사용하도록 설정합니다.

클러스터 는 로드 밸런서 뒤에 여러 ownCloud 애플리케이션 서버가 있는 배포 환경입니다. 이러한 구성에서는 한 애플리케이션 노드에서 생성된 잠금이 다른 모든 노드에서 볼 수 있어야 합니다. 노드별 APCu 캐시 또는 노드별 별도의 Redis 인스턴스는 이러한 공유 잠금 상태를 제공할 수 없습니다.

ownCloud 클러스터형 공유 스토리지 가이드에서는 모든 애플리케이션 노드에서 접근 가능한 하나의 공유 Redis 인스턴스를 사용하도록 명시적으로 권고하고 있습니다. 또한 ownCloud의 애플리케이션 수준 잠금에 파일 시스템 또는 NFS 잠금을 사용하는 것을 경고합니다.

모든 노드에서 동일한 Redis 엔드포인트와 자격 증명을 사용하는지 확인하십시오. 흔히 발생하는 오류 패턴은 한 노드가 여전히 데이터베이스 또는 로컬 Redis를 사용하는 반면 다른 노드는 공유 서비스를 사용하는 경우입니다. 이로 인해 일관성 없는 잠금 동작이 발생하여 각 요청을 처리하는 애플리케이션 노드에 따라 결과가 달라지기 때문에 간헐적으로 오류가 발생하는 것처럼 보일 수 있습니다.

4단계: 구성을 확인하고 원래 작업을 다시 시도합니다.

Redis 설정을 완료한 후에는 `check_ownCloud` 명령어를 사용하여 활성화된 ownCloud 설정을 확인하십시오 occ. 설치 환경에 따라 이 명령어는 웹 서버 사용자 권한으로 실행하거나 Docker Compose를 통해 실행할 수 있습니다.

sudo -u www-data php occ config:system:get memcache.locking
sudo -u www-data php occ config:system:get filelocking.enabled

첫 번째 명령은 오류를 보고해야 하며 \OC\Memcache\Redis, 트랜잭션 파일 잠금은 활성화된 상태로 유지되어야 합니다. 파일 잠금을 비활성화하여 문제를 "해결"하지 마십시오. 이는 백엔드 문제를 해결하는 대신 데이터 무결성 보호 장치를 제거하는 것입니다.

이제 실패했던 작업을 정확히 다시 시도해 보세요. 데스크톱 클라이언트 업로드 시간 초과가 발생했다면 해당 업로드를 다시 실행하세요. 폴더 이동이 실패했다면 이동을 다시 실행하세요. 테스트하는 동안 ownCloud 및 Redis 로그를 확인하세요. 잠금 시간 초과가 반복되지 않고 재시도가 성공적으로 완료되면 관련 없는 유지 관리 명령을 실행했다는 증거보다 훨씬 강력한 증거가 됩니다.

파일이 여전히 잠겨 있는 것으로 표시되면 어떻게 해야 할까요?

먼저 다른 작업이 해당 파일을 실제로 사용 중인지 확인하십시오. 대용량 업로드, 외부 저장소 호출, 파일 이동, 암호화 또는 느린 저장소로 인해 예상보다 오랫동안 잠금이 유지될 수 있습니다. 작업이 진행 중인 동안 잠금을 해제하면 잠금이 방지하도록 설계된 경쟁 조건이 발생할 수 있습니다.

트랜잭션 잠금은 트랜잭션이 중단된 후 해제되도록 설계되었습니다. 이전 ownCloud 구성 참조 문서에는 잠금 시간 제한(TTL) 메커니즘이 설명되어 있어 오래된 잠금을 자동으로 정리할 수 있습니다. 정확한 구성 세부 정보는 ownCloud 릴리스에 따라 다를 수 있으므로 변경하기 전에 설치된 버전에 맞는 문서에서 해당 옵션을 확인하십시오. 스토리지 또는 데이터베이스 속도 문제를 숨기기 위해 TTL을 지나치게 짧게 설정하지 마십시오.

메타데이터 자체에 일관성이 없는 경우 ownCloud는 복구 지향적인 파일 스캔 명령을 제공합니다. 공식 occ 명령 설명서에서는 복구 스캔을 실행하기 전에 데이터베이스를 백업할 것을 권장합니다. 복구 스캔은 손상되었거나 일관성이 없는 파일 메타데이터를 위한 것이며, 일반적인 잠금 경합에 대한 1차 해결책은 아닙니다.

트랜잭션 잠금과 수동 파일 잠금을 혼동하지 마십시오.

현재 ownCloud 11 문서에 따르면 웹 인터페이스에서 수동 파일 잠금은 기본적으로 비활성화되어 있습니다. 활성화할 경우 웹 인터페이스 잠금의 기본 시간은 30분이며 최대 기본값은 24시간입니다. 이러한 값은 수동 파일 잠금 가이드 에 설명되어 있습니다 .

사용자가 수동으로 설정한 잠금과 관련된 문제라면 다음과 같은 명령어가 도움이 될 수 있습니다.

docker compose exec owncloud occ config:app:set files lock_timeout_default --value 1800
docker compose exec owncloud occ config:app:set files lock_timeout_max --value 86400

파일 동기화 또는 저장 중 내부 시간 초과가 문제의 원인이라면, 이러한 수동 잠금 값을 변경하는 것은 일반적으로 잘못된 해결책입니다.

락 타임아웃을 악화시키는 일반적인 실수

ownCloud가 활성화된 상태에서 데이터베이스에서 잠금 행을 삭제합니다.

이는 실제 요청과 경쟁하여 유효한 잠금을 해제할 수 있습니다. 또한 타임아웃을 유발한 데이터베이스 또는 Redis 구성을 수정하지 않고 증상만 처리합니다.

트랜잭션 파일 잠금 비활성화

트랜잭션 잠금은 파일 작업이 동시에 수정되는 것을 방지하기 위해 존재합니다. 트랜잭션 잠금을 활성화한 상태로 유지하고 백엔드를 복구하십시오.

클러스터에서 공유 잠금을 위해 APCu 사용

APCu는 노드별 로컬 캐시입니다. 로컬 캐싱에는 적합하지만, 여러 애플리케이션 서버에서 공유되는 단일 잠금 상태를 제공하지는 않습니다. 클러스터 환경에서 분산 및 잠금 캐시를 사용하려면 공유 Redis를 사용하십시오.

애플리케이션 노드당 하나의 Redis 인스턴스를 실행합니다.

그 결과 각 서버는 파일 잠금에 대한 서로 다른 관점을 갖게 됩니다. 모든 노드는 잠금 조정을 위해 동일한 공유 Redis 서비스가 필요합니다.

경합 문제를 해결하지 않고 데이터베이스 잠금 대기 시간을 증가시키는 경우

데이터베이스 타임아웃 시간을 길게 설정하면 사용자 대기 시간이 길어질 뿐입니다. 트랜잭션 잠금 트래픽을 Redis로 이동하면 데이터베이스의 잠금 작업 부하가 줄어들고 아키텍처상의 병목 현상이 해결됩니다.

잠금 만료 기간을 비현실적으로 짧게 설정

느린 외부 저장소 작업이나 대용량 업로드에는 시간이 필요할 수 있습니다. 잠금이 너무 일찍 만료되면 다른 요청이 동일한 리소스를 동시에 수정할 수 있게 됩니다.

빠른 문제 해결 체크리스트

• 오류가 사용자 수동 잠금이 아닌 트랜잭션 잠금과 관련된 것인지 확인하십시오.
• ownCloud, PHP, 데이터베이스 및 Redis 로그를 동일한 시간대에 확인하십시오.
• Redis가 셸뿐만 아니라 ownCloud 런타임에서도 접근 가능한지 확인하십시오.
• memcache.locking로 설정하세요 \OC\Memcache\Redis.
• 활성화 상태로 유지하세요 filelocking.enabled.
• 클러스터 환경에서는 모든 노드가 동일한 Redis 인스턴스를 가리키도록 설정해야 합니다.
• 로그를 모니터링하면서 원래 동기화, 업로드 또는 이동 작업을 다시 시도하십시오.
• 메타데이터 손상이나 오래된 잠금이 원인이라는 증거가 있을 때만 복구 스캔 또는 잠금 만료 변경을 사용하십시오.

결론적으로

ownCloud 파일 잠금 시간 초과 오류를 해결하는 가장 확실한 방법은 잠금을 제거하거나 임의의 시간 초과 값을 높이는 것이 아닙니다. 먼저 오류가 트랜잭션 잠금에서 발생하는지 확인한 다음, 해당 잠금 워크로드를 Redis로 이동하고 모든 ownCloud 노드가 동일한 Redis 인스턴스를 사용하도록 설정하십시오. 오류가 발생한 작업을 다시 테스트하고, 잠금이 여전히 너무 오랫동안 활성화된 상태로 유지되는 경우 데이터베이스 또는 스토리지 지연 시간을 조사하십시오.

이 접근 방식은 현재 ownCloud 문서에 따릅니다. 즉, 트랜잭션 파일 잠금은 계속 활성화되고, Redis는 공유 잠금 상태를 처리하며, 수동 파일 잠금 시간 초과 설정은 범용 잠금 시간 초과 수정이 아닌 별도의 기능으로 취급됩니다.