MariaDB 백업은 복원으로 검증한다 — 격리 DB 복원 리허설과 무결성 확인표
도입 dump 명령이 성공하고 파일이 존재해도 그 파일이 원하는 시점과 범위의 데이터를 복원한다는 보장은 없다. 백업은 격리된 환경에 복원하고 구조·데이터·애플리케이션 읽기를 확인해야 운영 가능한 복구 수단이 ...
검색
백업 검색 결과: 11개
-
-
MariaDB Expand-Contract 마이그레이션 — 무중단 컬럼 변경을 단계별로 검증하기
도입 컬럼을 한 번에 바꾸면 이전 애플리케이션과 새 애플리케이션이 동시에 동작하는 배포 구간에서 한쪽이 실패할 수 있다. Expand-Contract는 호환 가능한 구조를 먼저 추가하고 사용 전환이 끝난 뒤 오...
-
AWS EC2 인스턴스의 구성 요소와 실무 운영 기준
도입 웹 서비스를 직접 운영하려면 애플리케이션이 실행될 컴퓨터가 필요하다. 물리 서버를 구매하면 초기 비용과 설치 시간이 발생하고, 트래픽 변화에 맞춰 용량을 조정하기도 어렵다. Amazon Elasti...
-
PHP 개발에서 AI 결과를 어디까지 사용할까 — 작업 위험도별 검증 게이트
AI로 코드 초안을 빠르게 만드는 것과 안전하게 배포하는 것은 다른 문제다. 같은 코드 생성이라도 README 문구 수정과 인증 로직 변경의 위험은 같지 않다. 따라서 “AI를 사용했는가”보다 작업의 영향도에 맞는 ...
-
AWS Well-Architected로 소규모 EC2 서비스를 점검하기 — 발견 사항을 개선 작업으로 바꾸는 표
AWS Well-Architected Framework의 여섯 원칙을 정의하는 것만으로 시스템은 바뀌지 않는다. 목적은 현재 구성의 위험과 의사결정 근거를 찾아 우선순위가 있는 개선 작업으로 만드는 것이다. 이 글은...
-
대용량 테이블 분할 전략 — 파티셔닝과 샤딩의 차이와 선택 기준
데이터가 수천만 건을 넘어가면 단일 테이블 구조는 점점 한계에 부딪힌다. 인덱스 크기가 커지고, 백업·복구 시간이 길어지며, 특정 쿼리의 응답 속도가 급격히 저하된다. 이 시점에서 고려하는 전략이 파티셔닝(P...
-
서버 다운 시 복구 프로세스 정리 — 점검 순서와 운영 대응 기준
운영 중 서버가 다운되면 가장 중요한 것은 “빨리 고치는 것”이 아니라 “순서대로 확인하는 것”이다. 무작정 재부팅부터 하면 원인 분석이 불가능해지고, 동일 장애가 반복된다. 복구 프로세스는 감각이 아니라 절...
-
장애 대응·포스트모템·온콜·DB 장애 시나리오 정리
이 글은 서비스 장애·안정성과 관련된 네 가지 주제 — 장애 대응 체크리스트, 포스트모템 작성 방법, 온콜(On-call) 경험 정리, 데이터베이스 장애 시나리오 — 를 개발자·운영자 관점에서 정리한 메모이다. ...
-
PHP 서비스의 저장소 선택 — MariaDB로 시작하고 Redis·문서 DB를 추가하는 판단 기준
데이터베이스 제품의 기능을 나열하는 것만으로는 저장소를 선택하기 어렵다. PHP 웹 서비스에서는 데이터의 정본이 무엇인지, 어떤 일관성이 필요한지, 실패했을 때 어떻게 복구할지를 먼저 결정해야 한다. 이 글은 회원·...
-
서버 운영 시 생길 만한 오류와 처리·방지 방법
서버 운영 중 자주 발생하는 오류와 그에 대한 처리 방법, 그리고 사전 방지 방안을 정리한 내용이다. 디스크, 메모리, 프로세스, 네트워크, 로그 관련 항목을 중심으로 서술한다. 1. 디스크 풀 (Disk Fu...