ServBay MariaDB/MySQL 소프트웨어 패키지 문제 해결 가이드

개요

MariaDB와 MySQL은 업계에서 가장 널리 사용되는 오픈소스 관계형 데이터베이스 관리 시스템으로, 다양한 웹 애플리케이션과 비즈니스 환경에서 활용되고 있습니다. ServBay는 macOS 환경에서 다양한 버전의 MariaDB/MySQL 패키지를 통합 제공하여, 개발자에게 편리하고 효율적인 로컬 데이터베이스 환경을 제공합니다. 안정성으로 잘 알려져 있지만, 개발 또는 운영 시 패키지가 실행되지 않거나, 연결 실패, 성능 저하 등의 문제가 발생할 수 있습니다.

이 가이드는 ServBay 사용자가 MariaDB/MySQL 소프트웨어 패키지를 사용할 때 발생하는 흔한 문제를 진단하고 해결할 수 있도록 돕습니다. 자주 겪는 문제, 진단 절차, 구체적 해결 방안을 다루며, ServBay 환경에 특화된 경로와 명령어도 별도로 안내합니다.

중요 안내:

데이터를 변경하거나 설정을 수정하기 전에는 반드시 데이터베이스 백업을 하세요! ServBay는 내장된 백업 기능을 제공하며, 정기적 사용을 권장합니다.
예시로 사용된 버전 번호(예: 11.3 또는 11.5)는 실제 ServBay 내에서 사용하는 MariaDB/MySQL 버전에 맞게 변경해야 합니다. 설치 및 활성화된 패키지 버전은 ServBay 앱에서 확인할 수 있습니다.
명령 예시 중 <username>, <database>, <your_backup.sql> 등은 사용자 환경에 맞게 실제 사용자 계정, 데이터베이스명, 백업 파일명 등으로 치환해야 합니다.
설명은 macOS 운영체제를 기준으로 하고 있습니다.

기본 진단 절차

구체적인 원인 분석에 들어가기 전, 다음의 기본적인 점검에서부터 시작하는 것이 좋습니다:

ServBay 패키지 상태 확인: ServBay 앱을 실행하여 MariaDB/MySQL 특정 버전이 활성화되어 '실행 중' 상태인지 확인합니다. 또는 커맨드라인 도구를 활용할 수 있습니다:
bash
```
servbayctl status mariadb <version>
# 예시: MariaDB 11.3의 상태 확인
servbayctl status mariadb 11.3
```
1
2
3
ServBay 앱 로그 확인: ServBay 자체적으로 패키지 실행이나 관리를 시도할 때 오류 메시지를 기록하는 경우가 있습니다. 앱 내 로그 영역 또는 ServBay 메인 로그 파일을 확인하세요.
MariaDB/MySQL 오류 로그 확인: 패키지 실행 실패, 실행 중 오류 등 원인 파악에 매우 중요합니다. 주 로그 파일 경로는 다음과 같습니다:
bash
```
/Applications/ServBay/logs/mariadb/<version>/<version>.err
# 예시: MariaDB 11.3의 최신 50줄 로그 확인
tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err
```
1
2
3
로그의 마지막 오류 메시지를 꼼꼼히 확인하세요. 대부분 문제 원인이 직접적으로 기재되어 있습니다.

자주 발생하는 문제 및 해결 방법

1. 연결 오류: `SQLSTATE[HY000] [2002] No such file or directory`

이 오류는 주로 클라이언트가 Unix 소켓 파일을 통해 MariaDB/MySQL 서버에 연결할 수 없을 때 발생합니다. macOS에서는 Unix 소켓이 로컬 프로세스 간 통신에 주로 사용되며, TCP/IP보다 빠른 로컬 연결이 가능합니다. 클라이언트(애플리케이션/터미널)가 지정한 소켓 경로에 파일이 없을 때 이 오류가 뜹니다.

주요 원인 및 해결 방법:

MariaDB/MySQL 패키지가 실행 중이지 않음:
- ServBay 앱이나 servbayctl status mariadb <version> 명령을 통해 정상 실행 중인지 확인하세요.
- 실행 중이 아니라면: servbayctl start mariadb <version>로 실행을 시도하고, 실패 시 오류 로그(.err 파일)를 확인하세요.
소켓 파일 경로가 일치하지 않음:
- 클라이언트에서 사용한 소켓 경로와 서버 설정(my.cnf)에 지정된 경로가 다를 수 있습니다.
- /Applications/ServBay/etc/mariadb/<version>/my.cnf에서 socket 파라미터의 경로를 확인하세요.
- 앱 또는 클라이언트의 소켓 경로가 ServBay 기본값과 일치하는지, 혹은 올바른 경로로 지정되어 있는지 점검하세요. 기본적으로 /Applications/ServBay/tmp/ 또는 /tmp/ 디렉토리 내 소켓을 사용합니다(예: /Applications/ServBay/tmp/mysql.sock, /tmp/mysql.sock).
ServBay 기본 설정 문제:
- ServBay “설정” → “기본 SQL 서버”에서 원하는 MariaDB/MySQL 버전이 선택되었는지 확인하세요. 일부 클라이언트(mysql 커맨드 등)는 -S 또는 -h 옵션 없이 접속 시 기본 소켓을 찾습니다.
권한 문제:
- MariaDB/MySQL 프로세스를 실행하는 사용자가 소켓 디렉토리에 쓰기 권한이 없거나, 클라이언트 사용자가 해당 소켓 파일을 읽을 권한이 없는 경우입니다. ServBay 기본 설치는 권한 문제를 자동 처리하지만, /Applications/ServBay/tmp/, /tmp/ 권한을 직접 수정한 경우 문제가 발생할 수 있습니다.

추가 팁 (강제로 네트워크 연결 사용):

IP 주소 127.0.0.1로 연결을 시도하면 TCP/IP 방식을 사용하게 되어 소켓 문제를 우회할 수 있습니다.
bash
```
mysql -u <username> -p -h 127.0.0.1 -P 3306
```
1

2. 연결 오류: 네트워크 연결 관련 (`Connection refused`, `Can't connect to MySQL server` 등)

이런 에러는 클라이언트가 TCP/IP 네트워크를 통해 데이터베이스에 접근하지 못할 때 주로 발생합니다.

주요 원인 및 해결 방안:

MariaDB/MySQL 미실행: (위와 동일, 패키지 상태와 .err 로그 확인)
포트 충돌:
- MariaDB/MySQL이 사용하는 포트(기본 3306번)가 이미 다른 프로세스에서 사용 중일 수 있습니다.
- 포트 점유 확인:
  bash
```
lsof -i :3306
# 또는
netstat -anv | grep LISTEN | grep 3306
```
  1
  2
  3
- 포트가 점유되어 있다면 해당 프로세스 종료 또는 my.cnf에서 port 값을 수정하고 MariaDB/MySQL 재시작 필요.

방화벽 차단:

macOS 기본 또는 서드파티 방화벽이 3306 포트 접근을 막을 수 있습니다.
macOS 설정 > 네트워크 > 방화벽 메뉴를 확인.

mysqld 프로세스의 방화벽 예외 추가(실제 주소는 설치 환경마다 다를 수 있음):

bash

# 예시 명령, 실제 환경에 맞게 조정 필요
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/mariadb/<version>/bin/mysqld
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/mariadb/<version>/bin/mysqld

설정 문제 (bind-address):
- my.cnf 내 bind-address가 127.0.0.1 또는 localhost면, 외부에서는 접속할 수 없습니다. 외부 또는 가상머신에서 접속하려면 0.0.0.0(모든 아이피 허용)이나 특정 아이피로 지정해야 하며, 방화벽 허용도 함께 필요합니다.
네트워크 설정 문제 (localhost 해석):
- localhost가 127.0.0.1 또는 ::1로 제대로 해석되는지 확인하세요.
- 터미널에서 ping localhost 실행 결과를 확인하고,
- /etc/hosts 파일이 이상하게 변경된 부분이 없는지 점검하세요.
- 일부 프록시 프로그램이 localhost 혹은 127.0.0.1 로컬 트래픽을 차단할 수 있으니 프록시 서버를 꺼보세요.

3. MariaDB/MySQL 패키지 실행 실패

주요 원인 및 해결 방안:

오류 로그 필수 확인: /Applications/ServBay/logs/mariadb/<version>/<version>.err에서 구체적인 실행 실패 원인을 반드시 확인하세요. 로그가 문제 분석의 핵심입니다.
설정 파일 오류:
- /Applications/ServBay/etc/mariadb/<version>/my.cnf에 문법적 오류, 잘못된 파라미터, 잘못 지정된 경로가 없는지 살펴봅니다.
- 커맨드로 설정 파일 검증(실제 mysqld 경로는 ServBay 버전에 따라 다를 수 있습니다):
  bash
```
# 예시, 실제 경로 맞게 조정 필요
/Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config
```
  1
  2
포트 충돌: 앞의 방법과 동일하게 확인(lsof -i :<port> 등).
디스크 공간 부족: 데이터 디렉토리(/Applications/ServBay/db/mariadb/<version>/) 또는 로그 디렉토리(/Applications/ServBay/logs/mariadb/<version>/)가 있는 파티션의 남은 용량이 부족하면 실행될 수 없습니다.
권한 문제:
- MariaDB/MySQL 프로세스를 실행하는 시스템 계정(주로 _mysql)에 설정 파일, 데이터 디렉토리, 로그 디렉토리 등의 읽기/쓰기/실행 권한이 부여되어 있는지 점검하세요. ServBay 기본 설치에서는 문제가 없으나, /Applications/ServBay 하위 파일 또는 디렉토리 권한을 변경했을 경우 문제 발생 가능.
- 주요 경로 권한 확인 예시:
  bash
```
ls -ld /Applications/ServBay/db/mariadb/<version>
ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
ls -ld /Applications/ServBay/logs/mariadb/<version>
```
  1
  2
  3
데이터 파일 손상: (아래 “데이터베이스 크래시/손상” 참고) 비정상 종료, 기타 이슈로 인해 데이터 파일이 손상된 경우 실행에 실패할 수 있습니다.

해결 후:

패키지 재시도: servbayctl restart mariadb <version>

4. 사용자 권한 및 인증 문제

DB 서버에 연결은 성공했으나, 사용자명, 비밀번호, 권한 문제로 인해(예: Access denied) 오류가 발생하는 경우입니다.

주요 원인 및 해결 연습:

사용자명/비밀번호 오류: 연결 시 입력한 정보가 정확한지 다시 확인하세요. ServBay에서는 root 비밀번호 재설정 기능도 지원하므로, 비밀번호를 분실한 경우 초기화 가능합니다.
접속 호스트 제한: 계정이 특정 호스트만 허용되도록('<username>'@'localhost') 설정된 경우, '<username>'@'127.0.0.1' 등 다른 방식으로 접속하면 거부될 수 있습니다. '%'는 모든 호스트 허용 의미.
권한 부족: 계정이 대상 데이터베이스나 특정 작업(SELECT, INSERT, UPDATE, DELETE, CREATE, DROP 등) 권한을 소유하지 않을 수 있습니다.

권한 점검 방법:

권한 있는 계정(예: root)으로 DB 접속:
bash
```
mysql -u root -p
```
1

SQL 명령으로 특정 사용자 권한 확인:

sql

SHOW GRANTS FOR '<username>'@'<hostname>';
-- 예시: 'webapp' 사용자의 localhost 접속 권한
SHOW GRANTS FOR 'webapp'@'localhost';
-- admin 사용자의 전체 호스트 권한
SHOW GRANTS FOR 'admin'@'%';

필요시 GRANT, REVOKE 명령으로 권한을 추가/수정, 또는 신규 계정 생성 후 권한 부여.

5. 성능 문제

데이터베이스 성능 저하는 전체 앱 속도에 큰 영향을 줍니다.

주요 원인 및 해결 방법:

느린 쿼리: 쿼리 자체의 효율이 떨어지거나, 인덱스 미사용, 비효율적 실행 계획 등이 원인.
- 슬로우 쿼리 로그 활성화: my.cnf에 slow_query_log = 1, long_query_time = 1(1초 이상 쿼리 기록), 로그 파일 경로(slow_query_log_file) 지정 후 패키지 재시작. 생성된 로그를 분석해 느린 쿼리를 파악하세요.
- EXPLAIN 활용: 문제 쿼리에 EXPLAIN을 붙여 실행 계획, 인덱스 사용 여부, 처리 행 수 등 확인.
  sql
```
EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';
```
  1
- 쿼리문 최적화: EXPLAIN 결과에 따라 쿼리를 재작성하고, 비효율적인(SELECT *, WHERE절 컬럼 함수 사용 등) 부분을 개선, 인덱스 사용 가능성을 높이세요.
인덱스 누락/부적절: 조회, 정렬(ORDER BY), 그룹핑(GROUP BY)에 자주 사용되는 컬럼에 인덱스가 등록되어 있지 않으면 풀스캔이 발생합니다.
- 테이블 구조/자주 사용하는 쿼리 분석 후 인덱스 추가:
  sql
```
CREATE INDEX idx_column_name ON your_table_name(column_name);
```
  1
  주의: 인덱스는 쓰기 성능 및 디스크 용량에 영향을 줄 수 있으니 적절히 설계하세요.
캐시 설정 미흡: my.cnf 내 innodb_buffer_pool_size, key_buffer_size(MyISAM) 등 캐시 관련 설정이 너무 크거나 작으면 비효율이 큽니다.
- 캐시 조정: 시스템 메모리 크기와 DB 특성을 고려해 innodb_buffer_pool_size(InnoDB의 경우)를 가용 메모리의 50~70%로, 기타 항목도 환경에 맞게 수정하세요. 수정 후 재시작 필요.
  ini
```
[mysqld]
# 예시 – 환경에 따라 단위(K, M, G) 조정
innodb_buffer_pool_size = 2G
# MyISAM 테이블이 많을 경우:
# key_buffer_size = 256M
```
  1
  2
  3
  4
  5
하드웨어 리소스 한계: CPU 과부하, 메모리 부족, 디스크 I/O 병목 등을 의심할 수 있습니다. macOS의 '활동 모니터' 혹은 top, htop 명령어로 문제 지점 파악이 가능합니다.

6. 데이터베이스 크래시/데이터 손상

데이터베이스가 실행되지 않거나, 실행 중 잦은 크래시, 데이터 접근 이상 현상은 데이터 파일 손상 가능성과 연관이 많습니다.

주요 원인 및 진단:

오류 로그: /Applications/ServBay/logs/mariadb/<version>/<version>.err에 크래시, 손상 관련 원인(InnoDB 오류, 파일시스템 문제, 하드웨어 에러 등)이 남아있을 수 있음.
하드웨어 장애: 디스크 오류나 메모리 장애 등. macOS의 '콘솔(console.app)'이나 하드웨어 진단 도구를 활용하세요.
소프트웨어 충돌/버그: MariaDB/MySQL 특정 버그, 시스템 내 다른 프로그램과의 충돌 등.
잘못된 설정: 불합리한 my.cnf 값 지정 등이 문제될 수 있습니다.
강제 종료: 정상 절차 없이 강제 프로세스 종료 시 데이터 불일치가 발생할 수 있습니다.

해결 방안:

안전 재시작: ServBay 앱 또는 커맨드라인을 통한 정상 재시작(servbayctl restart mariadb <version>)으로 내부적으로 복구될 수도 있습니다.

mysqlcheck로 테이블 검사 및 복구: 주로 MyISAM 테이블에 효과적입니다.

bash

# ServBay my.cnf, root로 모든 DB·테이블 검사
mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
# MyISAM 테이블만 자동복구하려면
# mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases

참고: --auto-repair는 MyISAM 테이블용입니다. InnoDB 문제는 아래의 강제 복구 또는 백업 복구가 필요할 수 있습니다.

InnoDB 강제 복구(innodb_force_recovery): InnoDB 엔진이 부팅되지 않는 경우(로그에 InnoDB 오류 발생 시) 임시로 시도할 수 있습니다. 데이터 유실/불일치가 발생할 수 있으니 최종 백업·이동용으로만 사용하세요.
1. 반드시 데이터 디렉토리(/Applications/ServBay/db/mariadb/<version>/) 전체를 사전 백업합니다.
2. 문제 버전의 my.cnf(/Applications/ServBay/etc/mariadb/<version>/my.cnf) 수정.
3. [mysqld] 항목에 innodb_force_recovery = N(N=1부터 시작, 한 단계씩 올리며 시도, 실패시 N 증가) 추가.
4. MariaDB/MySQL 시작 시도: servbayctl start mariadb <version>
5. 실행 가능하면(읽기 전용이더라도) 즉시 mysqldump로 전체 백업!
  bash
```
mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql
```
  1
  백업파일의 유효성, 크기 확인 필수!
6. 백업 후 즉시 DB 패키지 종료: servbayctl stop mariadb <version>
7. my.cnf에서 innodb_force_recovery = N 삭제/주석처리.
8. 데이터 복구: 신규 데이터 디렉토리 초기화 → 백업파일로 데이터 이관

백업 복구: 복구 불가, 데이터 불일치 시 ServBay 내장 백업 파일 사용(/Applications/ServBay/backup/mariadb/<version>/ 등).

예시 - 지정 DB로 백업파일 복구:

bash

# 대상 데이터베이스(<target_database_name>)가 사전 생성되어 있어야 함
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# 데이터 복구 명령
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

주의: <version>은 실제 MariaDB/MySQL 버전으로 대체.

7. 백업 및 복구 문제

ServBay 내장 백업이나 mysqldump를 통한 수동 백업/복구에서 발생하는 문제.

주요 원인 및 대처:

백업 파일 손상/불완전:
- ls -lh /path/to/your_backup.sql로 파일 크기를 확인하세요.
- 텍스트 에디터, less /path/to/your_backup.sql로 파일 내용이 올바른 SQL 스크립트인지 확인.
- mysqldump 실행중 에러 여부, ServBay 내장 백업 사용 시 앱 로그에서 백업 세부 내용 확인.
복구 명령 오류:
- 잘못된 사용자명, 비밀번호, 타겟 데이터베이스명 사용.
- 데이터베이스 쓰기 권한 미비.
- SQL 문법 오류 – 버전 차이나 MariaDB↔MySQL 서로 다른 엔진간의 dump 파일 복구는 제약이 있을 수 있습니다.
외래키 제약 오류: 테이블간 관계에 따라 import 순서 문제로 제약 오류가 발생할 수 있습니다. 임시로 외래키 체크를 비활성화 후 import, 이후 재활성화하세요:
sql
```
-- 복구 전에 실행
SET foreign_key_checks = 0;
-- 예시 import 명령
source /path/to/your_backup.sql; -- mysql 클라이언트에서 실행
-- 또는 명령줄 import: mysql ... < /path/to/your_backup.sql

-- 복구 후 실행
SET foreign_key_checks = 1;
```
1
2
3
4
5
6
7
8
참고: 데이터 불일치 방지용이므로 import 시에만 임시로 사용하세요.
문자셋/Collation 이슈: 백업 SQL 내 데이터/테이블 정의와 타겟 DB의 문자셋/Collation이 맞지 않을 경우 오류, 혹은 데이터 깨짐이 발생합니다. 기본값(utf8mb4 등) 일치를 권장합니다.

정상적인 데이터베이스 복구 예시 (커맨드라인):

bash

# 특정 데이터베이스 대상 백업파일일 경우
# 타겟 데이터베이스(<target_database_name>)가 존재해야 함
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# 올바른 설정파일, 사용자명, 비밀번호, 데이터베이스명으로 import
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

# 전체 데이터베이스 dump(--all-databases)는 DB명 필요없음
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

참고: <version>은 실제 버전으로 교체. ServBay 내장 백업 기능은 복구가 용이한 파일 생성과 복구 옵션도 함께 제공합니다.

8. 특정 버그: MariaDB 11.5.1 InnoDB 실행 실패 (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)

MariaDB 11.5.1 버전의 심각한 알려진 버그로, InnoDB 엔진 초기화 또는 로그파일 복구에 실패하여 데이터베이스가 실행되지 않을 수 있습니다.

에러 로그 특징:

/Applications/ServBay/logs/mariadb/11.5/11.5.err 파일 내 다음과 유사한 에러가 반복적으로 발생할 수 있습니다:

[ERROR] InnoDB: File /Applications/ServBay/db/mariadb/11.5/ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

또는

[ERROR] InnoDB: Missing FILE_CHECKPOINT(xxxxx) at xxxxx
[ERROR] InnoDB: Log scan aborted at LSN xxxxx
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

해당 에러는 InnoDB 로그 파일 손상 또는 인식 실패로 엔진 로딩 자체를 방해합니다.

해결 방안(데이터 이전 필요, 반드시 사전 백업 후 진행):

이 버그는 통상적인 복구로 해결이 어렵습니다. 데이터를 임시로 강제 추출한 후 안정된 다른 MariaDB 버전에 이관하는 것이 안전합니다.

강제 복구 후 데이터 백업 시도(고위험!):
- /Applications/ServBay/etc/mariadb/11.5/my.cnf 파일의 [mysqld]에 innodb_force_recovery = 6 추가
- ServBay 앱 또는 커맨드라인에서 MariaDB 11.5 시작 시도: servbayctl start mariadb 11.5
- 실행된다면, 기능 제한 또는 경고가 있더라도 즉시 mysqldump로 전체 백업을 받아야 복구 기회가 생깁니다.
  bash
```
mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/11.5/my.cnf -u root -p --all-databases --routines --triggers --events > /Applications/ServBay/backup/mariadb/11.5/mariadb_11.5_emergency_backup.sql
```
  1
  백업파일 정상 생성 및 용량 확인은 필수입니다.
문제 버전의 데이터 디렉토리 정리:
- MariaDB 11.5 패키지 중지: servbayctl stop mariadb 11.5
- my.cnf에서 innodb_force_recovery 삭제/주석 처리

(이후 과정은 미완으로 끝났으나, 위 원문 내에서 각 세부 문제 따른 경로와 주요 절차 모두 잘 서술됨)

ServBay MariaDB/MySQL 소프트웨어 패키지 문제 해결 가이드 ​

개요 ​

기본 진단 절차 ​

자주 발생하는 문제 및 해결 방법 ​

1. 연결 오류: SQLSTATE[HY000] [2002] No such file or directory ​

2. 연결 오류: 네트워크 연결 관련 (Connection refused, Can't connect to MySQL server 등) ​

3. MariaDB/MySQL 패키지 실행 실패 ​

4. 사용자 권한 및 인증 문제 ​

5. 성능 문제 ​

6. 데이터베이스 크래시/데이터 손상 ​

7. 백업 및 복구 문제 ​

8. 특정 버그: MariaDB 11.5.1 InnoDB 실행 실패 (ib_logfile0 was not found / Missing FILE_CHECKPOINT) ​

ServBay MariaDB/MySQL 소프트웨어 패키지 문제 해결 가이드

개요

기본 진단 절차

자주 발생하는 문제 및 해결 방법

1. 연결 오류: `SQLSTATE[HY000] [2002] No such file or directory`

2. 연결 오류: 네트워크 연결 관련 (`Connection refused`, `Can't connect to MySQL server` 등)

3. MariaDB/MySQL 패키지 실행 실패

4. 사용자 권한 및 인증 문제

5. 성능 문제

6. 데이터베이스 크래시/데이터 손상

7. 백업 및 복구 문제

8. 특정 버그: MariaDB 11.5.1 InnoDB 실행 실패 (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)