서버 한번 옮기려니 신경쓸게 너무 많네요. 정보
서버 한번 옮기려니 신경쓸게 너무 많네요.
본문
아웃소싱 하자니 그렇고
직접하자니 지식이 없고
그냥 두자니 언제 뻑날지 몰라 불안하고
옮기자니 안옮기니만 못할까봐 걱정스럽고
하다 막혀서 질문을 하면 답변이 오는데 이틀이상 지나고
답변이 시답잖아 재질문을 하면 다시 이틀이상 지나 답변이 오고
가만히 있기도, 나아가기도, 물러서기도 애매한 상황이 되어 버렸네요.
이런 상황을 뭐라고 하나요?
추천
2
2
댓글 26개
진퇴양난?
@똥싼너구리 정답입니다. ㅎ
aws 파트너업체 통해 진행하세요. 비용은 추가될수 있지만, 위와 같은 고민을 해결해줄수 있는 엔지니어들이 많습니다. 소개해드릴까요?
서버내 작업은 아무것도 하지 않는 것이 최선이라고 저 신입 때 사수가 그랬어요.
@잉끼s 네 맞습니다. ㅎ
그런데 안 옮길수 없는 상황이 다가와서요. ㅠ
그런데 안 옮길수 없는 상황이 다가와서요. ㅠ
일단 전문업체에 의뢰하고 (고민90%해결) 천천히 공부하세요(고민10%해결) .....%는 아무기준없는 제 개인생각입니다 ^^
@하늘아래구름 저도 제발 그렇게 했으면 좋겠습니다. ㅎ
혹시나 AWS 같은 클라우드로 옮기는 계획이시라면 저도 알려드릴수 있을것 같네요.
AWS 7년차이고 AWS Solutions Architect 자격증 가지고 있습니다.
AWS 7년차이고 AWS Solutions Architect 자격증 가지고 있습니다.
@라엘 지금 가장 큰 문제가 SIR DB를 마이그레이션 하면서 부하가 걸려 작업이 중단된 상태입니다.
https://ap-northeast-2.console.aws.amazon.com/dms/v2/home?region=ap-northeast-2#dashboard
엔드포인트 소스, 타겟을 정하여 마이그레이션 실행을 하면 소스 DB쪽 서버에 부하가 걸리네요.
AWS 지원팀에서도 이 부분에 대해 질문 남긴지 한참 지났는데 아직 답변이 없습니다. ㅠ
실제 운영되는 서버를 서버 중단 없이 AWS 로 옮겨 오면 되는데 쉽지 않네요.
https://ap-northeast-2.console.aws.amazon.com/dms/v2/home?region=ap-northeast-2#dashboard
엔드포인트 소스, 타겟을 정하여 마이그레이션 실행을 하면 소스 DB쪽 서버에 부하가 걸리네요.
AWS 지원팀에서도 이 부분에 대해 질문 남긴지 한참 지났는데 아직 답변이 없습니다. ㅠ
실제 운영되는 서버를 서버 중단 없이 AWS 로 옮겨 오면 되는데 쉽지 않네요.
@리자 원본 DB 는 mysql 이죠? 디비 용량이 100GB 이상인가요 이하인가요?
@라엘 100기가 이하입니다.
덤프 했을때 말씀이신가요? 이것도 100기가 이하입니다.
덤프 했을때 말씀이신가요? 이것도 100기가 이하입니다.
@리자 그럼 그냥 일반적으로 옮겨도 금방 될듯하네요.
디비 이외의 리소스는 이미 옮기셨나요?
디비 이외의 리소스는 이미 옮기셨나요?
@라엘 네 그거야 뭐... 그런데 DB가 상당히 말썽이더라구요.
AWS RDS에서 4천만건 RESTORE 시키는데 하루가 더 걸리는거 있죠?
매뉴얼상에 나온대로 했는데도 그렇게 되네요.
뭐 특별한 옵션을 준것도 없는데 말이죠.
AWS RDS에서 4천만건 RESTORE 시키는데 하루가 더 걸리는거 있죠?
매뉴얼상에 나온대로 했는데도 그렇게 되네요.
뭐 특별한 옵션을 준것도 없는데 말이죠.
댓글 깊이가 최대치가 되어서 답글이 안되네요.
대량의 데이터 복구는 순간적으로 큰 IOPS를 필요로 합니다. RDS는 IOPS제한이 있기 때문에 이론적인(문서에 나온) 동작을 하지 않습니다. (복구 돌리고 rds metric 에 iops 를 보면 알수 있습니다. 최대치에 리밋걸리는게 보일걸요.)
Large volume 환경은 mysqldump 등으로 복구하시면 안되고 infile 형태로 백업& 복구해야 합니다.
대량의 데이터 복구는 순간적으로 큰 IOPS를 필요로 합니다. RDS는 IOPS제한이 있기 때문에 이론적인(문서에 나온) 동작을 하지 않습니다. (복구 돌리고 rds metric 에 iops 를 보면 알수 있습니다. 최대치에 리밋걸리는게 보일걸요.)
Large volume 환경은 mysqldump 등으로 복구하시면 안되고 infile 형태로 백업& 복구해야 합니다.
@라엘 전문적인 지식이 없어 힘드네요. infile 형태는 테이블별로 생성을 해야 하는것이죠? 그럼 작업이 너무 복잡해지겠네요. 알려 주셔서 감사합니다. 찾아 보도록 하겠습니다.
처음 사이트 구축할 때는 저가 웹호스팅으로 시작해서 몰랐는데,
어느정도 지식도 생기고, 사이트 운영도 짬이 붙어서, 서버호스팅으로 옮겼는데,
생각보다 서버 관리를 직접한다는게 쉬운 일이 아니더라고요.
서버를 몇 번 직접 이전해 보기도 했지만 그때마다 셋업도 여간 번거로운 일도 아니고..
좀 실력이 붙었다고 나름 튜닝(?)도 해보고 그랬는데 가장 좋은 건 사람들이 선호하는 세팅만 하고 안 건드리는게 정신, 신체적으로 좋더라고요..;;
어느정도 지식도 생기고, 사이트 운영도 짬이 붙어서, 서버호스팅으로 옮겼는데,
생각보다 서버 관리를 직접한다는게 쉬운 일이 아니더라고요.
서버를 몇 번 직접 이전해 보기도 했지만 그때마다 셋업도 여간 번거로운 일도 아니고..
좀 실력이 붙었다고 나름 튜닝(?)도 해보고 그랬는데 가장 좋은 건 사람들이 선호하는 세팅만 하고 안 건드리는게 정신, 신체적으로 좋더라고요..;;
@마루밑다락방 맞습니다. 건드리기 시작하면 끝이 없습니다.
실제 운영하는 서버 잘못되면 식은땀 나죠.
실제 운영하는 서버 잘못되면 식은땀 나죠.
서버 업그레이드는 너무 힘들죠..그래도 힘내세용...
@와이쿠 가끔씩 만지니 더 힘드네요. 새로 배우는 느낌입니다. ㅎ
소스서버쪽 디비가 뻗어버리고 했던 경험을 한적 있었는데
물리적으로 불가능 할때에는
한번에 옮기지 마시고 디비를 천천히 동기화 시켜주는
코드를 짠 후 서버에 부하가 걸리지 않을 정도로 며칠을 돌려주어서
결국에 서로 동기화 되도록 한 다음
이전 했던 경험이 있습니다.
처음에 테스트로 해보고
속도 조절하면서 만드니 소스 서버에 부하가 걸리지만 멈추지는 않을 정도로
조절이 가능했었습니다.
계속 동기화 하는 cron을 돌리다가 100% 동기화가 되었을 경우
소스서버에 디비 connection 정보만 바꾸어서 디비서버 이전을 합니다.
물리적으로 불가능 할때에는
한번에 옮기지 마시고 디비를 천천히 동기화 시켜주는
코드를 짠 후 서버에 부하가 걸리지 않을 정도로 며칠을 돌려주어서
결국에 서로 동기화 되도록 한 다음
이전 했던 경험이 있습니다.
처음에 테스트로 해보고
속도 조절하면서 만드니 소스 서버에 부하가 걸리지만 멈추지는 않을 정도로
조절이 가능했었습니다.
계속 동기화 하는 cron을 돌리다가 100% 동기화가 되었을 경우
소스서버에 디비 connection 정보만 바꾸어서 디비서버 이전을 합니다.
@똥싼너구리 네 AWS에서 제공하는 서비스가 있어서 이용하려는데 SOURCE 쪽 서버에 부하가 걸리는 문제가 발생하여 문의해 놓은 상태입니다.
답변이 하세월 이네요. ㅠ
감사합니다.
답변이 하세월 이네요. ㅠ
감사합니다.
가끔 서버 이전을 하다 보면, 같은 환경으로 옮기는 경우가 없는 것 같습니다.
이건 뭐 OS 부터 모든 것들이 다 업그레이드 되거나 변경이 되어서, 맨땅에 헤딩하게 되더군요. ㅎㅎ
이건 뭐 OS 부터 모든 것들이 다 업그레이드 되거나 변경이 되어서, 맨땅에 헤딩하게 되더군요. ㅎㅎ
@마스타 네 맞습니다. 처음부터 다시 배워서 진행하는 느낌입니다. ㅠ
phpmyadmin 으로 테이블별로 백업 하시거나
또는 mysql에서 직접 테이블별로 백업 하셔서 복구 하시는 방법도 고려해 보세요.
mysqldump 보다는 여러가지로 시간이 좀 더 거리겠지만 부하는 안걸릴듯 하네요.
고생이 많으십니다. 홧팅!!!
또는 mysql에서 직접 테이블별로 백업 하셔서 복구 하시는 방법도 고려해 보세요.
mysqldump 보다는 여러가지로 시간이 좀 더 거리겠지만 부하는 안걸릴듯 하네요.
고생이 많으십니다. 홧팅!!!
