실성을 반대로

[MySQL 8.0/PHP] Server sent charset (255) unknown to the client 에러 해결기 레거시 PHP 환경에서 MySQL 8.0 / Aurora v3 연동 시 발생하는 문자셋(utf8mb4) 에러 원인 및 AWS RDS 파라미터 조치법 개발을 하다 보면 간혹 잘 작동하던 서비스나 새로 이전한 환경에서 뜬금없는 DB 연결 에러를 마주하곤 합니다. 오늘 정리할 오류는 PHP(특히 CodeIgniter 등 구형 프레임워크나 레거시 환경)에서 MySQL 8.0 이상(또는 AWS Aurora MySQL v3 등) 버전에 연결할 때 발생하는 전형적인 문자셋(Character Set) 에러입니다. 1. 발생한 에러 메시지 어느 날 갑자기 아래와 같은 PHP Warning 에러가 발생하며 DB 연결이 끊어지는 현상이 나타납니다. Severity: Warning Message: mysqli::real_connect(): Server sent charset (255) unknown to the client. Please, report to the developers Filename: mysqli/mysqli_driver.php Line Number: 161 이어서 (HY000/2054): Server sent charset unknown to the client 라는 메시지도 함께 출력됩니다. 2. 왜 발생했을까? (원인 분석) 이 에러의 핵심은 "DB 서버가 쓰는 최신 표준 언어(문자셋)를 구형 PHP 클라이언트가 알아듣지 못해서" 발생합니다. MySQL 8.0+ / Aurora v3+의 변화: MySQL 8.0 버전부터 기본 문자셋(Default Character Set)이 기존 utf8 에서 이모지까지 완벽 지원하는 utf8mb4 로 변경되었습니다. 이때 서버가 클라이언트에 전달하는 ...

"아이패드 크롬만 로그인이 안 돼요" — 특정 기기 버그 추적기와 Nginx 트랩 iOS 크롬과 HSTS 캐시, 그리고 Nginx absolute_redirect가 만들어낸 로드밸런서 HTTPS 다운그레이드 해결기 "갤럭시 탭 크롬은 되고요, 아이패드 사파리도 되는데, 아이패드 크롬만 로그인이 안 돼요." 운영하다 보면 이런 신고가 제일 골치 아픕니다. 특정 브라우저, 특정 기기에서만 재현되는 버그. 코드를 아무리 들여다봐도 "브라우저마다 다르게 동작할 이유"가 안 보이거든요. 이 글은 그 신고 한 건이 사실은 Nginx가 로드밸런서 뒤에서 HTTPS를 HTTP로 떨어뜨리던 고전적인 인프라 함정이었다는 걸 추적한 기록입니다. 1. 현상 파악: 골치 아픈 특정 환경 재현 버그 관리자 대시보드에서 다른 시스템으로 넘어가는 로그인 버튼이 있는데, 이게 특정 환경에서만 실패했습니다. 🔍 환경별 재현 결과: 📱 아이패드 크롬: 실패 ❌ 📱 아이패드 사파리: 성공 ⭕ 🤖 갤럭시탭 크롬: 성공 ⭕ 💻 PC (모든 브라우저): 성공 ⭕ "크롬 문제다"라고 단정하기엔 갤럭시 크롬은 멀쩡합니다. "iOS 문제다"라고 하기엔 사파리는 됩니다. 딱 iOS × 크롬 교집합에서만 터지는 기괴한 상황이었습니다. 2. 로그 분석: 결정적 차이 (Referer) 증상이 아니라 데이터를 봅니다. 백엔드 Referer 검증 로그를 실패/성공 케이스로 나란히 놓으니 결정적 차이가 한 줄에 드러났습니다. ❌ 아이패드 크롬 (실패 로그) referer: http://app.example.com/ ← http, 그리고 루트 경로 허용목록: ['https://adm...

MySQL 8에서 사라진 PASSWORD() 함수, 어떻게 대처해야 할까? MySQL 8.0 업그레이드 후 발생한 PASSWORD() 삭제 문제와 임시 대처법 및 권장 해결책 MySQL을 5.x 버전대에서 8.0 이상으로 업그레이드한 개발자라면 한 번쯤 마주쳤을 법한 오류가 있습니다. 바로 이전에 잘 사용하던 PASSWORD() 함수가 더 이상 작동하지 않는 문제입니다. 기존에는 아래와 같은 쿼리로 사용자의 비밀번호를 손쉽게 해시하여 저장할 수 있었습니다. -- MySQL 8.0 이전 버전에서 사용되던 방식 UPDATE user SET password_column = PASSWORD('my_password'); 하지만 MySQL 8.0부터 PASSWORD() 함수는 지원 중단(deprecated) 후 완전히 제거되었기 때문에, 위 쿼리를 실행하면 오류가 발생합니다. 왜 PASSWORD() 함수가 사라졌을까? 가장 큰 이유는 보안 입니다. PASSWORD() 함수는 'mysql_native_password' 인증 방식에 사용되는 해시 값을 생성했는데, 이 해싱 알고리즘은 솔트(salt)를 사용하지 않는 오래된 방식입니다. 최신 보안 표준에 비해 취약점이 존재하여, MySQL 8.0부터는 기본 인증 플러그인이 더 강력한 caching_sha2_password 로 변경되면서 PASSWORD() 함수도 자연스럽게 사라지게 된 것입니다. 임시 해결책: PASSWORD() 함수 직접 구현하기 만약 기존 시스템과의 호환성 문제로 PASSWORD() 함수와 동일한 결과값이 반드시 필요한 상황이라면, 아래와 같이 수동으로 해시 값을 생성할 수 있습니다. 이는 기존 함수의 내부 동작을 SQL로 그대로 구현한 것입니다. UPDATE user SET password_column = CONCAT('*', UPP...

[Aurora MySQL 8.0] DATE 컬럼 조회 시 Incorrect DATE value: '' 에러 분석 MySQL 5.7 ➡️ 8.0 업그레이드 후 WHERE date_col = '' 쿼리가 에러(ERROR 1525)를 내는 이유와 sql_mode 동작 원리 AWS Aurora MySQL 5.7에서 8.0으로 업그레이드를 진행한 후, 기존 서비스에서 잘 작동하던 DATE 타입 컬럼 조건문에서 뜬금없이 에러가 발생하는 현상을 마주쳤습니다. 결론부터 말하면 WHERE date_col = '' 처럼 빈 문자열을 조건으로 넣었을 때 에러가 발생하는데, 정작 WHERE date_col = '0000-00-00' 조회를 시도하면 정상 작동하는 이상한 상황이 펼쳐집니다. 원인을 단계별로 정리해 둡니다. 1. 문제의 배경: sql_mode 옵션 (NO_ZERO_DATE / NO_ZERO_IN_DATE) MySQL에는 날짜 처리 방식을 결정하는 두 가지 핵심 sql_mode 옵션이 존재합니다. NO_ZERO_DATE • Enable: 0000-00-00 값을 유효하지 않은 날짜(Invalid date)로 인식하여 저장/조회를 제한합니다. • Disable: 0000-00-00 값 저장을 허용합니다. NO_ZERO_IN_DATE • Enable: Month나 Day 부분에 0이 포함된 날짜(예: 2022-12-00 , 2022-00-01 )를 Invalid date로 처리합니다. • Disable: 해당 형태의 날짜 입력을 허용합니다. MySQL 5.7 및 8.0부터는 기본적으로 이 두 옵션이 활성화되어 있어, 데이터가 없는 테이블에 아래 조회를 수행하면 ...

아파치 2.4에서 특정 IP를 차단하는 가장 깔끔한 방법 RequireAll 및 Require not ip 구문을 활용한 깔끔하고 안전한 접근 제어 설정 가이드 웹 서버 관리 시 특정 IP 주소로부터의 접근을 차단해야 하는 경우가 종종 발생합니다. 예를 들어 보안상의 이유로 특정 공격 IP를 막거나, 불필요한 트래픽을 유발하는 IP를 차단할 때 유용합니다. 아파치(Apache) 2.4 버전부터는 기존의 Order , Allow , Deny 지시어 대신 Require 지시어를 기반으로 한 새로운 접근 제어 방식이 도입되었습니다. 이 글에서는 Require not ip 를 사용하여 특정 IP를 차단하는 방법을 VirtualHost 설정 파일 기준으로 설명합니다. 1. 설정 파일 확인 및 수정 주로 사용하는 VirtualHost 설정 파일( .conf 확장자, 예: 000-default.conf 또는 도메인명.conf )이나, 전역 설정을 위한 httpd.conf 파일을 수정합니다. 차단할 IP를 적용할 <VirtualHost> 블록 내부에 <Location> 태그를 사용하여 접근 제어 설정을 추가합니다. 여기서는 웹사이트의 전체 경로( Location / )에 적용하는 것을 예로 듭니다. 📝 설정 코드 예시 <VirtualHost *:80> ServerAdmin XXXXXXX DocumentRoot XXXXXXX ErrorLog XXXXXXX CustomLog XXXXXXX # ↓↓↓ 특정 IP 차단 설정 시작 ↓↓↓ <Location /> <RequireAll> # 1. 일단 모든 접근을 허용합니다. (기본적으로 모두 열어둠) Require all granted #...

[MySQL/MariaDB] DB CPU 70% 폭주 원인 분석과 Slow Query 트러블슈팅 웹사이트 지연 장애 발생 시 SHOW PROCESSLIST 및 slow_log(BLOB 변환)를 활용한 실무 해결 가이드 웹서비스 운영 중 अचानक 사이트 접속이 느려지거나 500 에러가 간헐적으로 발생한다는 제보를 받았습니다. DB 모니터링을 즉시 확인해보니 DB Server의 CPU 점유율이 70% 이상 까지 급증한 상태였습니다. 실제 장애 현장에서 어떤 순서로 원인을 추적하고 해결했는지 단계별로 정리해 둡니다. 1. 현재 실행 중인 스레드 확인 (SHOW PROCESSLIST) 가장 먼저 DB에서 병목을 일으키는 쿼리가 무엇인지 확인하기 위해 현재 실행 중인 스레드 목록을 조회했습니다. SHOW PROCESSLIST; 출력 주요 컬럼: ID , USER , HOST , DB , COMMAND , TIME , STATE , INFO 조회 결과, TIME 이 100초 이상 지속되며 실행 중인 스레드가 다수 발견되었습니다. COMMAND 가 Query인 항목의 INFO 컬럼을 보니 특정 SELECT 문이 문제였습니다. 💡 TIP: 긴 쿼리가 중간에 잘려서 보일 때 기본 SHOW PROCESSLIST; 는 INFO 컬럼의 긴 쿼리를 일부만 보여줍니다. 이때 SHOW FULL PROCESSLIST; 를 사용하면 잘림 없이 전체 쿼리문 확인이 가능합니다. ⚠️ 주의: KILL {ID} 명령어 사용 시 참고할 점 부하를 급하게 줄이기 위해 문제 스레드를 강제 종료( KILL ID; )할 수 있습니다. 단, INSERT , UPDATE , DELETE 같은 CUD 작업은 강제 종료 시 트랜잭션 롤백 지연 이나 데이터 불일치 위험이 있으므로, 단순 조회( SELE...