설치된 확장 보기
INFORMATION_SCHEMA 뷰를 사용하여 설치된 확장을 쿼리합니다:- 인터랙티브 세션과 스크립트 모두에서 사용 가능
- MySQL 도구와 호환되는 표준 SQL 인터페이스
확장 함수 확인
설치 후 확장 함수가 정상 작동하는지 확인합니다:확장 디렉터리
VillageSQL이.veb 파일을 찾는 위치를 확인합니다:
veb_dir 구성
확장 디렉터리 위치를 변경하려면 MySQL 구성 파일에veb_dir을 설정합니다:
my.cnf / my.ini:
- 경로는 절대 경로여야 함(상대 경로 불가)
- 서버 시작 전 디렉터리가 존재해야 함
- MySQL 사용자에게 디렉터리 읽기 권한이 있어야 함
- 하나의
veb_dir만 지원됨(여러 경로 불가) - 변경 사항은 서버 재시작 후 적용됨
문제 해결
빠른 참조
확장을 찾을 수 없음
오류:Extension 'my_extension' not found
디버그 단계:
설치 후 함수 사용 불가
오류:FUNCTION my_func does not exist
디버그 단계:
업데이트 후 확장이 오래된 동작 보여줌
현상:.veb 파일을 교체하고 재설치한 후 확장이 여전히 오래된 코드 실행
원인: VillageSQL은 .veb 파일을 처음 로드할 때 {datadir}/.veb_expansion_cache/에 전개합니다. UNINSTALL EXTENSION을 실행하지 않고 새 .veb를 복사하면 서버는 이미 메모리에 로드된, 이전에 전개된 .so를 계속 사용합니다.
해결 방법: 항상 UNINSTALL → 교체 → INSTALL 순서를 따르세요:
veb_dir의 .veb 파일을 교체하고 재설치합니다:
확장 제거 불가
오류:Cannot uninstall extension: types in use
해결 방법:
라이브러리 로딩 오류
오류:Cannot load library: undefined symbol
원인:
- 라이브러리 종속성 누락
- ABI 호환성 불일치
- 잘못된 MySQL 버전
확장 이름 검증 오류
오류:Failed to load VEF extension 'extension_name' 및 로그 메시지 Extension name mismatch
원인: manifest.json의 확장 이름이 VEB 파일 이름과 일치하지 않음.
디버그 단계:
-
VEB 파일 이름이 매니페스트와 일치하는지 확인:
-
manifest.json의 name 필드 확인:
- VEB 파일 이름:
my_extension.veb - manifest.json:
"name": "my_extension"
- 매니페스트에 하이픈 사용:
"name": "my-extension"❌ - VEB 파일 이름 불일치:
my-extension.veb대"name": "my_extension"❌
사용자 정의 유형 비교 오류
오류:Cannot compare types X and Y in =
원인: 비교 양쪽 모두 사용자 정의 유형이지만 서로 다른 유형 또는 확장에서 유래합니다.
오류:
Unable to implicitly cast a non-custom type during compare with a custom type in =
원인: 비교의 한쪽은 사용자 정의 유형 열이고 다른 쪽은 해당 유형으로 자동 변환할 수 없는 값(리터럴 또는 열).
확장 사용 모니터링
쿼리 성능
performance_schema를 사용해 VDF 실행 시간 추적:사용자 정의 유형 사용
사용자 정의 유형을 사용하는 테이블 추적:확장 업데이트
설치된 확장을 다른 버전으로 변경하려면ALTER EXTENSION을 사용합니다.
이는 새 버전을 기존 데이터와 대조하여 검증하고, 다음 서버 재시작 시 변경을
적용합니다. 대안으로 수동 제거 및 재설치도 계속 사용할 수 있습니다.
확장 버전 변경
ALTER EXTENSION은 설치된 확장을 다른 버전으로 변경하며, 다음 서버 재시작 시
적용됩니다:
<name>-<version>.veb
(여기서는 update_test-1.2.0.veb)로 존재해야 하며, 파일이 없으면 거부됩니다:
INFORMATION_SCHEMA.EXTENSIONS는 현재 버전과 함께 변경될 대상 버전을
보고합니다:
INFORMATION_SCHEMA.EXTENSIONS는 예약된 변경을 네 개의 열로 보고합니다:
예약된 변경은 한 번에 하나만 추적됩니다:
- 예약된 변경을 취소하려면 현재 버전을 다시 요청합니다:
- 아무것도 예약되지 않은 상태에서 현재 버전을 요청하면 아무 작업도
수행하지 않습니다:
- 변경이 예약된 동안 다른 대상은 거부됩니다 — 먼저 기존 변경을
취소하세요:
AT RESTART 절은 다음 서버 시작 중에 변경을 적용합니다.
성공적인 재시작 후
다음 재시작 시 대기 중인 변경이 적용됩니다:EXTENSION_VERSION이 대상
버전이 되고 PENDING_VERSION이 클리어됩니다. 위에서 예약한 변경
(update_test 1.0.0 → 대기 중 1.2.0)의 경우:
custom_columns 및 저장 프로시저 매개변수 행은
동일한 재시작 중에 다시 작성되므로, 종속 테이블과 루틴은 수동 마이그레이션
없이 계속 작동합니다.
변경은 재시작 중에 적용되며 라이브 연결에서는 적용되지 않습니다 — 위의 값은
재시작 후 상태입니다.
시작 시 대기 중인 버전 변경 복구
예약된 버전 변경은 다음 서버 시작 중에 적용됩니다. 대기 중인 작업을 적용할 수 없는 경우, 서버가 시작에 실패할 수 있으며, 대기 중인 업데이트 결정 사항은 디스크에 그대로 유지됩니다. 대기 중인ALTER EXTENSION ... AT RESTART가 시작을 차단하고 있고
이를 클리어하기 전에 서버를 가동해야 할 때는
--villagesql-skip-extension-updates를 사용하세요.
--villagesql-skip-extension-updates는 mysqld 시작 플래그입니다. 설정되면
서버는 대기 중인 ALTER EXTENSION ... AT RESTART 작업의 처리를 건너뜁니다:
각 확장은 현재 설치된 버전으로 로드되고, 대기 중인 작업은 디스크에 그대로
유지됩니다. 플래그 자체는 아무것도 변경하지 않으며, 그 한 번의 시작 동안
대기 중인 작업의 적용만 건너뜁니다.
플래그가 설정되어 있고 적어도 하나의 확장에 대기 중인 작업이 있으면, 서버는 시작 시 몇 개의 대기 중인 업데이트를 건너뛰었는지 명시하는 경고를 한 번 로깅합니다:
1
플래그와 함께 서버 시작
프로덕션에서는 일반 개발 하네스에서는 성공 신호: 서버가 시작되고, 오류 로그에 위에 표시된
mysqld 명령줄 옵션으로 전달하거나 my.cnf의
[mysqld] 아래에 추가합니다:--로 전달합니다:bypassing N pending extension update(s) 경고가 포함됩니다.2
대기 중인 작업 식별
PENDING_VERSION은 클리어해야 할 대상이며,
PENDING_LAST_ERROR는 적용에 실패한 이유를 보여줍니다.3
각 대기 중인 작업 클리어
위에서 반환된 모든 확장에 대해, 현재 버전을 요청하여 대기 중인 변경을
취소합니다(확장 버전 변경에 설명된
취소 메커니즘):성공 신호:
Cleared pending update for extension '<name>' (target matches current version '<current>') 노트가 반환되고, 이전
쿼리를 다시 실행하면 PENDING_VERSION이 NULL로 표시됩니다.4
플래그 없이 재시작
--villagesql-skip-extension-updates를 생략하고 서버를 정상적으로
재시작합니다.성공 신호: 서버가 시작되고 로그에
bypassing N pending extension update(s) 경고가 더 이상 나타나지
않습니다.수동 업데이트 프로세스
-
현재 버전 제거:
-
.veb 파일 교체:
-
새 버전 설치:
-
업데이트 확인:
정리
고아 확장 디렉터리 제거
VillageSQL은.veb 파일을 {datadir}/.veb_expansion_cache/{name}/{sha256}/로 전개합니다. 오래된 버전이 시간이 지나 누적됩니다.
서버 재시작 시 고아 확장 디렉터리 자동 정리.
복제
사용자 정의 유형은 ROW 형식의 binlog를 요구합니다. STATEMENT 및 MIXED 모드는 사용자 정의 유형 열을 가진 테이블에 지원되지 않습니다. 사용자 정의 유형 열에 대한 INSERT, UPDATE, DELETE, ALTER TABLE 작업은 모두 ROW 형식에서 정상적으로 복제됩니다.INSTALL EXTENSION은 복제되지 않습니다 — 각 서버가 자체 확장을 관리합니다. 복제 시작 전에 모든 복제본에 동일한 버전으로 확장을 설치하세요. 서버는 정확한 버전 일치를 강제하며, 버전 불일치 시 복제가 중단됩니다.
복제본이 인식하지 못하는 사용자 정의 유형을 만나면 DDL 문(statement)에서 복제가 중단됩니다 — CREATE TABLE 또는 ALTER TABLE에서 종속 DML이 적용되기 전에 중단됩니다. 올바른 확장 버전을 설치한 후 복제를 재개합니다:
mysqldump은 출력에 전체 이름이 지정된(fully qualified) 사용자 정의 유형 이름을 유지합니다. 덤프를 가져오기 전에 대상 서버에 확장이 설치되어 있으면 논리적 복원이 정상적으로 작동합니다.
Docker와 확장 사용
VillageSQL을 Docker에서 실행할 때, 컨테이너를 다시 빌드하지 않고도 호스트에서.veb 파일을 추가할 수 있도록 로컬 디렉터리를 veb_dir로 마운트합니다.
Docker Compose 예시:
./extensions/에 .veb 파일을 복사한 후 SQL에서 설치합니다:
도움 요청
이 문서에 포함되지 않은 문제에 직면했을 때:- 오류 로그 확인: 대부분의 확장 오류는 세부 정보와 함께 로깅됨
- 확장 문서 검토: 확장별 문제 해결 방법이 있을 수 있음
- Discord에서 문의: VillageSQL Discord에 가입
- 이슈 제출: GitHub Issues에서 버그 보고
다음 단계
시스템 참조
시스템 테이블 및 뷰 쿼리
확장 제거
확장 안전하게 제거
확장 아키텍처
내부 구조 이해

