이전 작업이 고통스러워지는 이유는 대개 기술이 아니라 순서 실수입니다. DNS를 먼저 바꾼 뒤에야 데이터베이스가 오래된 상태임을 발견하는 경우가 많습니다. 아래 순서를 따르면 방문자는 이전 사실을 눈치채지 못합니다.
1단계: DNS TTL을 미리 낮추기
이전하기 최소 하루 전에 A 및 AAAA 레코드의 TTL을 300초로 설정하세요. 이전 값을 이미 캐시한 곳이 만료되려면 시간이 필요하므로, 당일에 서두를 수 없는 단계입니다.
2단계: 새 서버를 먼저 구축하기
새 VPS를 만들고 보안 강화 체크리스트를 적용한 뒤 동일한 스택(웹 서버, PHP 또는 Node 버전, 데이터베이스 엔진)을 설치하세요. 버전을 맞추면 대부분의 돌발 상황이 사라집니다. 콘텐츠만이 아니라 설정도 복사하세요.
3단계: 파일 복사하기
rsync -aHAX --info=progress2 -e ssh /var/www/ user@NEW_IP:/var/www/
지금 한 번 실행하세요. 처음에는 느리지만 반복할 때는 빠르며, 바로 그것이 목적입니다.
4단계: 데이터베이스 복사하기
# on the old server
mysqldump --single-transaction --routines --triggers mydb | gzip > mydb.sql.gz
scp mydb.sql.gz user@NEW_IP:~/
# on the new server
gunzip < mydb.sql.gz | mysql mydb
이것은 예행연습입니다. 테스트에 사용할 작동하는 복사본을 얻을 수 있습니다.
5단계: 사용자를 보내기 전에 테스트하기
hosts 파일을 편집해 내 컴퓨터가 새 서버를 가리키도록 하세요. NEW_IP example.com www.example.com을 추가합니다. 사이트를 둘러보고, 로그인하고, 양식을 제출하고, 테스트 주문을 해 보세요. 일반 사용자가 아직 이전 서버를 보는 동안 문제를 고치세요. 전환 전에도 작동하도록 DNS 챌린지로 TLS 인증서를 설치하세요.
6단계: 동결, 최종 동기화, 전환
- 이전 사이트를 점검 모드 또는 읽기 전용 모드로 전환하세요.
rsync와 데이터베이스 덤프 및 가져오기를 다시 실행하세요.- DNS 레코드를 새 IP로 변경하세요.
- hosts 파일 항목을 제거하고 다른 네트워크에서 확인하세요.
읽기 전용 시간은 보통 몇 분입니다. 쇼핑몰이나 로그인이 있는 사이트라면 한가한 시간에 일정을 잡으세요.
7단계: 지켜본 뒤 이전 서버 폐기하기
이전 서버를 며칠 더 유지하세요. 일부 리졸버는 TTL을 무시하므로 소량의 트래픽이 계속 들어옵니다. 가능하면 그 트래픽을 새 IP로 전달하거나 프록시하고, 로그를 확인한 다음 TTL을 정상 값으로 되돌리세요. 이전 서버를 삭제하기 전에 새 서버에서 새 백업을 만드세요.
동시에 다른 관할권으로 옮기시나요? 먼저 오프쇼어 호스팅 관할권 비교에서 선택지를 비교해 보세요.