이 글의 링크는 추후 제휴 링크로 바뀔 수 있으며, 그 경우 구매 시 수수료를 받을 수 있습니다.
이 글에서 다루는 것
데이터베이스 연결 오류를 설정이 틀린 경우와 서버 자원이 모자란 경우로 가르는 방법을 정리합니다.
같은 오류 화면이 반복되는데 접속 정보를 아무리 봐도 틀린 곳이 없는 분을 위한 글입니다.
읽고 나면 어떤 화면의 어떤 숫자를 보고 둘 중 하나로 판정할지 정해집니다.
결론부터: 오류가 뜨는 '시점'이 신호입니다
데이터베이스 연결 오류는 원인이 전혀 다른 두 가지가 같은 화면으로 나타납니다.
설정이 틀린 경우는 언제 열어도 똑같이 실패합니다.
접속 정보나 권한이 어긋난 상태라 시간이 지난다고 달라질 여지가 없기 때문입니다.
자원이 모자란 경우는 다릅니다.
평소에는 멀쩡하다가 방문자가 몰리는 시간대나 백업·업데이트가 도는 동안에만 깨지고, 잠시 뒤 새로고침하면 다시 열립니다.
그래서 고치기 전에 할 일은 수정이 아니라 관찰입니다.
아래 표의 어느 쪽에 해당하는지부터 가르십시오.
| 관찰 항목 | 설정 문제 쪽 | 자원 부족 쪽 |
|---|---|---|
| 재현 방식 | 새로고침해도 계속 실패 | 조금 뒤 다시 열림 |
| 발생 시각 | 시간과 무관 | 특정 시간대에 몰림 |
| 직전 변경 | 이전·주소 변경·설정 수정 직후 | 바꾼 것 없이 어느 날부터 |
| 관리자 화면 | 같이 안 열림 | 느리지만 열릴 때가 있음 |
| 볼 곳 | 접속 정보와 권한 | 메모리·연결 수 그래프 |
1단계: 오류 이름을 공식 문서에서 먼저 맞춥니다
워드프레스 공식 문서의 데이터베이스 연결 오류 항목
① 워드프레스 공식 문서는 이 화면을 'Error Establishing Database Connection'이라는 이름으로 따로 다룹니다.
검색할 때도 번역된 문장이 아니라 이 영문 이름으로 찾는 편이 정확합니다.
② 공식 문서가 첫 번째 원인으로 드는 것은 wp-config.php의 접속 정보입니다.
이름·비밀번호·호스트 중 하나라도 어긋나면 서버가 아무리 한가해도 연결은 실패합니다.
여기서 틀린 곳이 나오면 자원 이야기는 꺼낼 필요가 없습니다.
반대로 이 단계가 깨끗한데도 오류가 반복된다면 2단계로 넘어갑니다.
2단계: 오류를 파일로 남겨 '언제' 터지는지 봅니다
공식 디버깅 문서의 WP_DEBUG_LOG 설명 화면
① 화면에 뜬 오류만 보면 시각을 알 수 없습니다.
공식 디버깅 문서의 WP_DEBUG_LOG는 발생한 오류를 debug.log 파일로 함께 저장하게 하는 설정입니다.
기록을 하루이틀 모으면 판정이 쉬워집니다.
오류 줄의 시각이 특정 시간대에 뭉쳐 있으면 자원 쪽, 접속할 때마다 고르게 찍히면 설정 쪽입니다.
다만 이 설정은 진단용입니다.
방문자에게 오류 내용이 그대로 보이지 않도록 화면 출력은 꺼 두고, 원인을 찾은 뒤에는 되돌리는 편이 안전합니다.
3단계: 여유 메모리 그래프를 봅니다
공식 도움말 화면 - 서버 메모리 사용량 확인 항목
① 관리형 호스팅은 서버 메모리 사용량을 그래프로 보여 줍니다.
클라우드웨이즈 공식 도움말 기준으로 이 통계는 5분마다 갱신되고, 실제 사용량은 전체 사용량에서 캐시가 쓰는 양을 뺀 값으로 계산합니다.
같은 문서는 여유 메모리가 계속 100MB 아래에 머물면 애플리케이션이 오작동하거나 죽기 시작한다고 설명합니다.
데이터베이스 프로세스가 먼저 밀려나면 그 순간 연결 오류가 뜹니다.
그래프의 골짜기가 오류 기록의 시각과 겹치는지 대 보십시오.
두 시각이 맞아떨어지면 자원 부족으로 거의 확정할 수 있습니다.
4단계: 메모리 말고도 같이 보는 항목
공식 도움말 화면 - 서버 쪽에서 볼 수 있는 자원 항목
① 메모리 ② 프로세서 외에 트래픽과 디스크도 같은 자리에서 봅니다.
디스크가 꽉 차면 데이터베이스가 임시 파일을 쓰지 못해 연결이 끊기므로, 메모리만 보고 넘기면 원인을 놓칩니다.
프로세서 사용률이 길게 100%에 붙어 있을 때도 질의가 대기 시간을 넘겨 똑같이 연결 실패로 보입니다.
5단계: 연결 수와 캐시 서비스 상태
공식 도움말 화면 - 데이터베이스와 캐시 서비스 점검 항목
① 데이터베이스 항목에서는 동시에 열려 있는 연결 수를 봅니다.
한도에 닿으면 새 방문자의 요청만 거절되므로, 먼저 들어온 사람에게는 멀쩡해 보이는 상태가 됩니다.
② 캐시 서비스가 꺼져 있거나 멈춰 있으면 모든 요청이 데이터베이스까지 내려갑니다.
방문자 수가 그대로여도 연결 수만 몇 배로 뛰는 흔한 경우입니다.
연결 수가 한도 근처에서 평평하게 눌려 있다면 서버를 키우기 전에 캐시부터 살리는 쪽이 비용이 덜 듭니다.
자원 부족으로 판명됐다면
순서는 '캐시 복구 → 불필요한 플러그인 정리 → 그래도 모자라면 자원 증설'입니다.
앞 두 가지를 건너뛰고 요금제부터 올리면 같은 증상이 몇 달 뒤 그대로 돌아옵니다.
증설이 필요한 단계라면 관리형 호스팅은 메모리·프로세서를 요금제 단위로 올립니다.
오늘 공식 요금 페이지에서 확인한 클라우드웨이즈의 가장 낮은 구간은 월 14달러이고 그다음이 28달러이며, 카드 없이 쓰는 3일 무료 체험이 함께 안내돼 있습니다.
처음부터 높은 구간을 고를 이유는 없습니다.
위 그래프에서 여유 메모리가 바닥을 치는 날이 잦아질 때 한 칸 올리는 것으로 충분합니다.
가장 낮은 요금 구간이 어떤 사양인지 공식 요금 페이지에서 직접 확인하기
이 선택이 안 맞는 경우
자원 부족이 아니었다면 요금제를 올려도 오류는 그대로 남습니다.
1단계에서 접속 정보가 틀렸던 경우가 여기에 해당합니다.
해외 관리형 호스팅 자체가 안 맞는 분도 있습니다.
결제가 달러라 환율에 따라 원화 청구액이 달라지고, 한국어 고객지원이 없으며, 관리 화면과 문서가 영어입니다.
메일 호스팅은 포함되지 않아 업무용 메일은 따로 마련해야 합니다.
월 1만 원 안쪽의 공유 호스팅에서 오류 없이 돌아가고 있다면 옮길 이유가 없습니다.
관리형 호스팅이 어떤 구조인지 공식 소개 페이지에서 살펴보기
자주 묻는 질문
오류가 떴다가 혼자 사라졌는데 그냥 둬도 되나요
사라진 것이 아니라 그 시간대에만 자원이 모자랐던 것일 가능성이 큽니다.
기록을 남겨 두고 같은 시간대에 다시 찍히는지 사흘만 지켜보십시오.
메모리를 올리면 연결 수 한도도 같이 올라가나요
자동으로 따라오지는 않습니다.
연결 수는 데이터베이스 설정 값이라 자원과 별개로 보고, 공식 도움말의 데이터베이스 모니터링 항목에서 따로 확인합니다.
복구가 급할 때 가장 먼저 할 일은 무엇인가요
서버 재시작이 아니라 현재 메모리와 연결 수를 먼저 적어 두는 것입니다.
재시작하면 숫자가 초기화돼 원인을 다시 찾기 어려워집니다.
무료 체험으로 미리 재 볼 수 있나요
같은 글 수와 플러그인을 올려 두고 재 보는 정도는 됩니다.
실제 방문자 수까지 재현되지는 않으니 참고치로만 보십시오.
마무리
같은 오류 화면이라도 언제 터지는지에 따라 설정 문제와 자원 부족으로 갈립니다.
공식 문서로 오류 이름과 접속 정보를 먼저 지우고, 기록으로 시각을 모은 뒤, 여유 메모리와 연결 수 그래프를 그 시각에 대 보는 순서입니다.
자원 부족으로 판명됐더라도 캐시와 플러그인을 먼저 정리하고, 증설은 가장 낮은 구간에서 한 칸씩 올리는 것으로 충분합니다.
지금 오류가 주로 몇 시쯤 뜨고 그 시각의 여유 메모리는 얼마였나요.
댓글에 두 숫자를 남겨 주시면 위 다섯 단계 중 어디부터 보실지 짚어 드리겠습니다.
다음 글에서는 「방문자 몰릴 때 사이트가 죽는 이유와 대비」에 대해 알아보겠습니다.