관례들이 중요한 이유 - DB 백업

Robin·2024년 8월 6일

사담 100% 인트로

※ 오늘 글은 개발보단 경험 위주의 기록 겸 사담이 많으니 참고! ※

내겐 굉장히 애정이 가는 개인 테크 블로그가 있다. (호봄 테크블로그 👉 링크)
단순히 포폴용으로 만든 명목상의 사이트가 아닌, 프론트 메이트와 함께 꿈을 펼쳐나가는 소중한 공간이다. 시도해보고 싶은 기술과 언어는 많은데 회사에서는 아무리 노력해도 기회가 없으니, 현생을 쪼개가며 만든 자식(?) 같은 사이트다.

정성스럽게 다듬은 글만 올리고 싶은 나머지, 필기와 같은 노트들은 벨로그에만 올리고 차마 이 테크 블로그에는 글을 쓰지 못해 최신글이 올라간지 시간이 꽤 지났다.
그 사이 나는 전직장을 퇴사하게 되었고 퇴사한 순간부터 자바, 스프링은 물론 여러 개발 서적들을 읽으며 많은 개념들을 학습하고 있다. 공부가 이렇게 재밌는거였으면 학생때 마음껏 해볼걸 싶은 생각이 들 정도였다. (물로 퇴사해서 다 재밌는걸수도 있음^^)

자바스프링을 학습하고보니 Express+TypeScript로 작성한 호봄 테크블로그의 코드들의 아쉬운 부분들이 눈에 띄기 시작했고, 리팩토링하고 싶은 마음이 솟구쳤다.
그렇게 새로운 브랜치에 리팩토링을 시작했고, 이 덕분에 나는 제목과 같이 "사람들이 습관처럼 사용하는 개발 문화가 '왜' 중요한지, '왜' 필요한지"를 몸소 경험하고 깨달을 수 있었다.😮‍💨

우선 오늘은 그 중 데이터베이스 백업에 대해서 기록해보고자 한다!

DB 백업

전직장 업계 특성상 백업은 필수 중의 필수였다. 이미 몇십년 넘게 견고히 유지된 DB는 그 규모가 엄청났고, 백업DB는 너무나도 당연하게 그 중 한자리를 꿰차고 있었다.
점심시간이나 업무시간 중 틈이 날때마다 디비를 설계하신 시니어 분들께 이런저런 내용들을 여쭙고 낯선 DB에 대해 여쭤봤지만, 그때도 백업에 대해서는 여쭤볼 생각을 못했다. 왜냐면 그냥 당연히 있는것이었고, (사고가 터지지 않는 한) 접근할 일이 없기 때문이다.

그렇게 퇴사 후, 자바 스프링 프로젝트(바로가기 👉 링크)를 진행하며 백업DB의 개념이 떠올랐고, 오픈API의 특성상 해당 데이터를 보관해야겠다는 생각에 백업테이블을 만들었다. 개인적으론 뭔가 어설프긴 한데🤔, 자바스프링 자체가 처음이니 리팩토링은 당연한 일이고 우선 현 상황에서 정상작동하는 것에 의의를 뒀다.

그렇게 자바 스프링 프로젝트는 챙겼으면서. 왜 호봄 테크블로그는 챙기지 못했던 것일까.

모든 게시물의 내용들이 싹- 다 지워졌다.

기존 MongoDB에서 MySQL로 마이그레이션 할 때도 잘만 존재하던 모든 게시물의 내용들이 삭제되었다. 정말 귀신이 곡할 노릇이다. 물론 내가 아직 경험 부족인 이유가 크겠지... 로그 파일을 몇번이나 뒤져봤지만 당최 왜! 모든 컬럼은 살아있고 게시물 내용을 담는 컬럼만 싸그리싹싹 모~두 비워진걸까?

리팩토링을 하며 디비 연결 쪽 sync를 건드린 걸까? 로컬 띄우며 뭔가 꼬인걸까? 별 생각을 다해봤지만 아직까지 원인을 찾지 못했다. 하지만 불이 났는데 불난 이유를 찾을 시간은 없다. 불부터 꺼야한다. 우선 기존 MongoDB에 존재하는 11개의 게시물을 찾아 옮겼다.

그 과정 속, 과거 DB 마이그레이션 중 MySQL에만 작성한 4개의 게시물들을 포함하여 다시금 MongoDB에 백업한 대견한 나의 행적을 발견했다.🥺

그렇게 발견한 article_bak 컬렉션덕분에 테크블로그의 글들을 무사히 원복시킬 수 있었다. 하지만 매 순간 이렇게 대처할 수 는 없겠다라는 생각이 들었다. 매번 글을 쓸때마다 수작업으로 MongoDB document에 작성할수도 없는 노릇이니 말이다.

시니어분들이 그렇게 하는데에는 다 이유가 있다. 내가 아직 겪지 못했을뿐.

왜 굳이 그렇게 하지?
왜 굳이 그렇게 되어있지?

(위의 의문처럼 부정적 어조로 생각해왔던건 아니지만) 뭔가 이유가 궁금했던 장치들은 아직 내가 경험이 부족할뿐, '굳이' 그렇게 한 이유가 있다. 하지만 직접 겪으며 깨달으니 기분이 앙큼해지고 더 뇌리에 박히는 효과가 있다.

디비를 이중화하여 하나는 읽기용(백업용), 다른 하나는 업데이트용으로 작성할까 싶기도 하고... Master-Slave 구조와 백업DB는 살짝 다른 개념 같기도 해서 좀 더 공부를 해봐야겠다. 그냥 스냅샷을 떠놔야할까? 어찌됐든 코드를 다시금 짜봐야겠군...

  1. 새로운 MySQL(혹은 이외의 RDB)를 활용하여 백업디비로 활용한다.
  2. 현상태를 유지하여 version1의 MongoDB 속 article_bak 컬렉션을 백업디비로 활용한다.

굳이 관계형을 쓰는데 MongoDB를 백업 디비로? 라는 생각도 들지만... 오히려 형식의 자유도 장점으로 사용할 수 있을 것 같기도 하고🤔...(물론 무료 클라우드의 메리트도 분명있다ㅎㅎ) 이렇게 삭제됐을때 로그 이외의 장치?도 있으면 좋을 거 같고... 메이트와 이야기하며 좀 더 알아봐야겠다!

DB백업 이외에도 깨달은 부분들도 차차 작성해보고자 한다. 의문을 가지면 몸소 겪고 삽질해보는것도 나쁘지 않아보인다! 몸과 정신이 조금 힘들뿐^^!

profile
Always testing, sometimes dog walking

0개의 댓글