EC2 복구 회고록(블로그 글을 믿지 말자)

어디서 부터 잘못 됐을까...아...지금 생각하니 취준생 때 이런 일을 겪은게 좋은 공부했다 싶으면서도 기분이 썩 좋지는 않다

 

EC2 복구 회고록 이지만 결국 나는 (현재 상황으로는) 복구를 하지 못했다ㅠㅠ하지만 배운 것들이 많아 그냥 주저리 주저리 마음 정리, 지식 정리 할 겸 이 글을 쓴다

 

문제의 발생은 지금으로부터 한 3주 전 Swagger2.9 버전과 3.0 버전을 공부하면서 이것저것 적용해보겠다고 작디 작은 나의 EC2 프리티어에 war 파일을 마구마구 올리던 것으로 부터 시작되었다. 

 

2개의 프로젝트를 maven을 통해 war 파일로 빌드 했는데 1개의 프로젝트가 제대로 기능하지 못했다. 그렇게 EC2의 메모리를 생각하지 못하고 어느 날 저녁 SSH로 접근을 하든 톰캣을 80 포트로 띄우든 MySQL Workbench를 들어가려고 하든 무한 랙에 걸리는 상황이 발생했다. Workbench도 톰캣도 나에게 연결하는데 시간이 너무 걸려~~라는 오류를 알려줬기 때문에 나는 처음에 카페에서 공공 wifi를 써서 사람이 많으니까 느린 가 보다 라고 생각하고 핫스팟을 켰다. 하지만 상황은 달라지지 않았다. 그렇게 3개의 프로세스 중 마지막 남은 터미널에서 아무 반응하지 못하고 무한으로 연결하기 위해 돌고 있는 서버를 나는 내버려두었다. 왜냐하면 어떤 프로세스가 동작중인데 뭔가 잘 안된다고 윈도우에서 하는 것처럼 막 꺼버리면 나도 모르는 어떤 문제를 야기할 수 있다고 지난 오류를 해결하며 뼈저리게 느꼈기 때문이다(그것 때문에 개고생했지 난 이제 그런 일을 반복하지 않아!!)

 

그렇게 다른 공부를 하며 몇 시간이 흘렀을까 서버 역시 시간이 오래 걸린다는 오류를 뱉고 다음날이 되었다. 

 

다음날 갑자기 SSH, Workbench, 올려놓은 서버 접속 그냥 모조리 싹 다 안되는 것이다...헐 이게 무슨 일이지?? 

일단 나는 SSH가 안된다는 것이 이해가 안됐다. 아니 왜!!! 어제까지 멀쩡하게 잘됐는데 얘 왜 이래!! 일단 무슨 일인지 모르니까 터미널로 서버에 접속해서 로그를 찍어봐야겠다 싶었다. AWS에 들어갔는데 잉 상태검사 통과를 실패했다는 처음보는 오류를 보게 되었다...얜 또 뭐지....하...그래서 구글링을 해보니 일단 AWS 재부팅하고 뜨는 시스템 로그를 통해 오류를 분석하라고 했다. 그렇게 했다. 오류.....뭐 없었다...까만건 화면이요...하얀 건 영어로 된 외계어니라...AWS 공식 사이트를 뒤져가며 친절하게도 올려놓은 시스템 로그에서 발생할 수 있는 오류 로그 종류를 일일이 비교하며 음 내 오류는 여기 없네를 결론으로 냈다. 그렇게 재부팅을 하면서 왓? 갑자기 상태 검사 통과 됐네? 와 다행이다 라고 생각했다

 

그러나 여전히 SSH는 접속할 수 없었다. 하 뭘까 우리의 친구 ChatGPT에게 물어보러 갔다. 이런 쓸모 없는 녀석 얘가 말해주는 솔루션은 뭔가 이상하게 2% 부족하다. 내 상황을 정말 정확하게 말해야 하는 거 같다. 워낙 오류의 상황이 다양하니

 

후 또다시 무한 구글링을 시작했다. SSH를 퍼블릭으로 열어보랜다(하 내가 미쳤지 진짜....) . 했다 오 됐다!! 자 이제 데이터베이스 로그를 찍어보자

tail -n 100 로그 있는 경로 어쩌구 저쩌구~~

 

잉 얘 뭐야 왜 아무것도 음슴???

 

재부팅해서 데이터베이스가 꺼졌나... 다시 재시작...

 

그러나 재시작, 시작, 중지 명령어 다 되지 않았다....

 

하...데이터베이스 WorkBench 접속...

 

왜 또 안돼!!!

 

또다시 무한 구글링

 

오호 ibdata1, ib_logfile0이라는게 있구나. 스택오버플로우에서 얘를 다른 폴더를 만들어서 옮기라고 했다 음 뭐징 그게 의미가 있나 그래도 데이터를 지우는 건 아니니까 일단 해보자(데이터도 함부로 지우면 그냥 망하는거다 라는 걸 또 저번 오류에서 느꼈기 때문에 반복하지 않는다!!)

 

폴더를 만들고 옮겼더니 지자스!!! 데이터베이스 연결이 됐다...와 뭐지 폴더 그냥 임시로 만들고 옮겼는데 왜 되는거지??

이거에 대해서 공부하고 싶어서 구글링을 잠시 해봤다. 음 정확하게 설명해놓은 글을 없었다 ibdata1과 ib_logfile0이 데이터베이스의 데이터를 담고 있는 파일이구나 정도는 이해를 했다. 스택오버플로우 형도 왜 되는지는 알려주지 않았다

 

일단 이거부터 해결 마무리하고 다시 공부해봐야겠다는 생각에 WorkBench로 들어가서 데이터를 보는데

 

롸??

 

가장 중요한 게시판 정보를 담고있는 테이블의 정보를 불러 올 수 없단다

 

Error 1932 42s02 table ~~~~ doesn t exist in engine

(이 오류는 정말 보기만 해도 치가 떨린다)

 

아 이거 때문에 로컬도 안되고 배포된 서버도 안되고 다 안되는 거였구나. 그래도 다행히 나머지 1개의 디비 정보는 잘 살아 있었다. 그래 1개라도 잘 살아있는게 어디니...EC2를 새로 파서 잘되는 애라도 옮겨야 겠다. 그렇게 또 다음날이 되었다

 

상쾌한 아침. 컴퓨터를 키고 들어가서 그동안 비트나미라는 대중적이지 않은 서버를 배워서 썼으니 다들 많이 하는 우분투를 이참에 배워야겠다는 생각에 우분투로 서버를 만들었다. 톰캣 깔고 디비 깔고 워크밴치에 연결해서 Migration Wizard를 통해 테이블 정보를 import했다... 파일질라도 이번에 새로 공부했는데 명령어 안치고 GUI로 서버 구조 보니까 너무 편하고 좋더라. 아무튼 파일질라 통해서 war파일 올리니 1개는 살렸다 됐다 됐어ㅠㅠㅠ이제 엔진에 없다던 그 테이블 복구하러 가볼까

 

그리고 다음날 우분투가 다 안됐다...와 진짜 미쳐버리는 줄 알았다....톰캣, 배포된 서버 주소, 워크밴치, SSH 다 안됐다

그리고 문제는 원래 EC2 서버도 다 안됐다....나한테 왜 이래ㅠㅠㅠ

 

구글링을 또 몇 시간 했다....하....망했다 SSH 퍼블릭으로 열어놓으면 크롤링 되거나 그래서 털릴 수 있다고 한다. 잠깐 여담을 하자면 생각보다 많은 블로그 글들이 SSH를 퍼블릭으로 설정하라는 얘기를 많이 한다.. 그러면 안되는 거였다 이 일을 통해 블로그 글을 크로스 체크하는 것이 얼마나 중요한지를 깨달았다...모니터링을 보니 내가 SSH를 퍼블릭으로 열어둔 바로 그때 이후!!!! CPU 사용률 그래프가 거의 100% 까지 치솟았다...클라우드 회사 다니는 아는 형에게 헬프 미를 외쳤다

 

몇 시간 동안 도와줬지만 결론은 그냥 인스턴스 새로 파란다...ㅠㅠㅠㅠ내 데이터베이스는 우짜지..물론 이것만으로 해킹을 당했는지는 판가름 할 수 없지만 어쨌든 결론은 이 서버는 터졌다는 것이다. 어찌저찌 톰캣은 죽어도 안되고 SSH 접속과 데이터베이스 워크벤치까지는 접속했다. 우분투 새로 파서 다시 옮겼다. 이정도도 감지 덕지라며 이제는 빨리 Error 1932 42s02 table ~~~~ doesn t exist in engine 이 에러코드를 해결해서 테이블 살리고 우분투 데이터베이스로 데이터를 옮기자는 생각밖에 없었다.

 

이것만 할 수 없고 스터디 하는 것도 있어서 그렇게 하루 몇 시간만 투자하며 별짓을 다했다. 서버가 2개가 돌아가서 금전적으로 부담이 돼 스터디 집중 기간에는 잠깐 우분투 서버를 껐는데 탄력적 IP를 적용하면 재부팅 후 IP가 바뀌지 않아서 편하다고 적용했는데 결론적으로 또!!! 또!!! 우분투 서버가 안됐다...이유는 모르겠다 물론 구글링을 했지만 알 수 없었고 해결해야 할 것도 공부해야 할 것도 너무 많아서 그냥 새로 파는게 빨랐다.

 

이 과정을 통해 권한 주는 법, 권한 바꾸는 법에 대한 명령어가 굉장히 많이 익숙해졌다. 그리고 왜 블로그에 사람들이 chmod 777을 무지성으로 말하는 지 알게 되었다. 777이 제일 편하다 소유자, 그룹, 공공에게 다 읽기 쓰기 실행 권한을 주니까 말이다. 하지만 굉장히 위험한 명령어이다. 그러나 많은 블로그 글들이 그 위험성에 대해서 경고하지 않았다. 작성자들도 구글링해서 참고했기에 그런 게 아닌 가 싶다. 755와 777의 차이는 뭐지 싶어서 공부하면서 깨닫게 된 것이다. 권한 옆에 rwx-dr 뭐시지 저시기 어쩌구 저쩌구가 무엇인지도 알게 되었다. 데이터베이스의 ibd파일과 frm 파일의 용도에 대해서 알게 되었다. 

 

이제 내가 한 돌이킬 수 없는 실수(지금 생각하기에) 얼추 마무리를 하려고 한다. 그리고 이 실수가 아 이건 정말 블로그를 통해 남겨 놓아야할 나의 경험이구나 라는 것을 깨닫게 했다

 

그전에 정말 내가 화나는 일이 있었다

 

https://frog-hindleg.tistory.com/208

[MariaDB] 마리아db "doesn't exist in engine" 오류 해결

다행히 이 글은 내가 ibdata1과 ib_logfile0가 필요한 것을 잘 알고 있었기 때문에 이렇게 하지 않았다

미친 게 아닐까 데이터를 다 지우라니...어떻게 이렇게 무책임하게 말할 수 있는 걸까

그리고 실제로 이 글 때문에 피해를 본 분이 있었던 거 같다

 

https://sir.kr/qa/338242

아 급하네요...,마리아DB 관련입니다. 도와주세요. > SIR

 

이걸 보고 와 진짜 블로그 글 믿을 게 못 되구나....크로스 체크 잘해야 하는 구나 무지성으로 따라하면 안되는 구나를 절실하게 깨달았다. 실제로 많은 글들이 다시 한번 말하지만 말도 안되는 해결 방법을 제시하는 경우가 많았다. 그냥 똑같은 내용을 복붙하거나 정말로 적용했는지 의심가는 내용들이 많았다. 많은 글들을 따라하면서 어 이거는 블로그에 없는 새로운 오류인데??? 이건 뭐지??? 이 사람은 어떻게 한거지?? 라는 게 너무나도 많았다....그리고 그 오류를 쳐보면

 

허허 여러분 이렇게 했을 때 이런 오류가 나오니까 조심하세요~~~

 

라는 글들이 많았다. 하지만 이런 글들은 정작 내가 오류를 해결하려고 검색하면 안 나오고 행동을 했을 때 새로운 오류가 뜨면 그제서야 검색이 된다는 것이다...(진작 좀 나오면 얼마나 좋을까)

 

그래서 복구할 수 없거나 뭔가를 지우는 행동은 진짜 진짜 하면 안된다ㅠㅠㅠ

 

그렇다고 구글링을 안하고 오류를 해결할 수 있는 방법은 지금으로써는 없는 거 같다. 다만 확실히 어떤 것을 지운다거나 복구할 수 없는 그런 행동들은 안하거나 미리 백업을 하든 뭘하든 차선책을 만드는 게 좋은 거 같다. 하지만 또 느낀 건 지식의 한계가 명확해서 지금 내가 하는 이 행동이 차선책을 잘 만든 건지도 알 수 없다는 거다. 그러니 최대한 부작용이 없는 방법을 취하고 충분히 많이 검색해보자ㅠㅠㅠ 

 

 

https://xinet.kr/?p=2611

innodb frm ibd 파일 가지고 복구하기 ( dbsake frm 추출)

 

그래서!!! 내가 위 글을 보고 바보같은 실수를 저질렀다는 것이다...여러 지식을 쌓으며 나는 얼추 어떻게 하면 해결할 수 있겠다는 꿈에 부풀어 있었고 위 글을 보게 되었다

 

이 글 중 백업 후 기존 데이터베이스를 지우라는 말이 있었는데 물론 나는 지우는 게 위험하다는 걸 알고 있었지만 이번에는 어차피 ibd랑 frm은 다 백업되어 있으니 괜찮겠지 라고 생각했다...그게 아주 큰 착각이었다

그렇게 나는 새로운 오류에 마주쳤다

 

https://itexit.tistory.com/120 

mariadb partition 다른 서버로 파티션 이관(복원)

하 이 글을 보고 욕이 절로 나왔다....내가 ibd, frm 파일 가지고 데이터베이스 복구 비스무리하게 검색할 때는 죽어도 이 글이 안 나왔고 대부분의 글들이 윗윗 글처럼 행동하라고 했다 물론 윗윗 글 처럼 rm -rf를 하라고 하지는 않았다....이건 정말 나의 큰 실수 였다....그러나 파일질라로도 cfg 파일은 전혀 보이지 않았다....정말 정말 생각치도 못한 오류 였다ㅠㅠㅠㅠ윗윗 글을 작성한 사람과 비슷한 해결방법을 제시한 작성자들에게 물어보고 싶다(사실 댓글로 욕을 하고 싶었다). 어떻게 이런 오류에 안 마주칠 수 있었냐고 정말 실행한 거 맞냐고...하지만 뭐 일부러 그랬겠는가 그저 나의 세부적인 상황과 달랐던게 아닐 까 싶다...내 실수 였고 미리 예방주사 맞았다고 생각하고 싶다

 

rm -rf 복구 방법을 또 미친듯이 구글링했지만 대부분의 해결방법은 file 복구 였고 나는 디렉토리를 지워서 아직까지는 방법을 모르겠다...대부분의 사람들도 rm -rf 하면 복구하기가 너무 어렵다고 한다. 그렇게 나에게 남은 건 빈 껍데기인 ibd파일과 frm 백업 본만 남았다. 그래서 현재까지는 데이터베이스를 날려 먹었다(고 생각한다) 

 

약 3주간 너무 심적으로 힘들었다. 새로운 오류가 계속 터지고 어제 되던 게 오늘은 안되고....머리 속이 너무 복잡해지고 머리 속에 계속 어떻게 해결해야 하지 라는 생각 밖에 안 들었다...오류 해결 과정은 재밌었지만 되던게 안되고 다음날 되면 또 안되고 이러니 그게 좀 힘들었다.....좋은 공부 였다고 생각한다.

 

그리고 찾아보니 회사 업무에서 이런 일을 마주친 사람들이 많은 거 같다...나는 그나마 다행이라고 생각한다 처음엔 왜 나에게만 이런 일이 일어날까 라고 생각했는데 이번 일을 토대로 회사 가서 조심해야겠다는 생각을 했다

 

첫 프로젝트였고 취준생이기에 얼마 없는 내 경험이 소중해 이것마저 없으면 정말 취업이 안되겠다고 생각해 간절하게 붙잡고 해결하기 위해 노력했지만 이제는 포기해야 할 꺼 같다

 

사실 백엔드적으로도 기능 구현한게 많이 없고 내세울 게 없어서 새로운 포트폴리오를 만들어야겠다고 생각한 요즘에 차라리 잘됐다 라는 생각도 들지만 또 다시 시간을 투자하고 취준 생활이 길어질 것을 생각하니 눈 앞이 아득하다.

 

개발은 재밌지만 취준 생활은 재미 없다ㅠㅠㅠㅠ 

 

정리!

 

배운 것

지식 영역

- EC2 우분투 서버 생성 후 우분투 내에서 톰캣, 자바, 데이터베이스 설치 및 war 파일 배포 

- FileZila 사용 법

- AWS 보안 그룹 설정

- 소유자, 그룹, 공공 권한에 대한 이해, chmod, chown 명령어 사용법

- 시스템 중지, 시작, 재시작 명령어 및 리눅스에서 각 시스템에 대한 로그 출력 방법

- EC2 내 데이터베이스 파일 구조 

- 백업 명령어

- ibdata1, ib_logfile0, .frm, .ibd 파일에 대한 이해

- AWS 탄력적 IP 설정 방법

- AWS 시스템 로그 보는 법

- 그 외 각종 리눅스 명령어

 

 

태도 영역

- 블로그 글을 믿지 말자. 반드시 충분히 검증하고 크로스 체크하자

- 함부로 데이터 지우지 말고 내가 할 행동에 대해 부작용을 항상 생각하자

- 내가 아는 지식 상에서 생각하지 말고 예측하지 말고 충분히 찾아보자

- 공부한다고 맘대로 서버 건드리지 말자

- 앞으로 내가 블로그 글을 쓸 때도 글을 보고 따라할 사람들의 상황에 대해 책임감을 가지고 안전한 지식을 쓰자

- 영어로 된 각종 사이트를 보는 게 굉장히 익숙해졌다

- 아무리 이해가 안되는 오류여도 이유가 있으니 차분히 잘 찾아보자

- 선택과 집중

나는 한번 파고 들기 시작하면 가끔 시간 상관없이 샛길로 빠질 때가 있다. 내가 이 지식을 정확하게 알아야 잘 사용할 수 있을 꺼 같아서 그렇다. 그러다 보니 시간은 시간대로 가는데 해결은 늦어질 때가 있었다. 이번 일을 통해 배운 것도 많았지만 내가 일단 먼저 문제 해결에 집중하고 나중에 못다한 공부를 따로 해야겠다는 생각이 많이 들었다.

한정된 시간...선택과 집중을 잘하자!