날씨가 점점 따뜻해지는 요즘이네요. 따뜻한 봄날을 맞아 오랜만에 평일에 영화를 관람해보았습니다.
힘든 헬요일을 극복하고자 월요일에 영화예매를 마치고, 무리해서 영화를 관람했고, 재밌는 시간을 보냈네요 😃
전날 토요일, 급하게 영화를 선정하였습니다. 현재 1위인 영화인 문폴을 선정했고, 예고편을 보지 않고 설정 자체가 재난영화로 보여 재밌게 볼수있겠단 생각으로 선택했습니다.
문폴 포스터
영화는 예상과는 많이 달랐습니다. 재난에 집중한 것이 아니라 원인을 파악하고 이 재난을 주인공 일행이 차근차근 해결해나가는 순서를 띠고 있었고, 이 과정에서 큰 비밀(!) 까지 밝혀지는, SF인줄 알고 시작했다가 판타지로 마무리되는 타입의 영화였습니다.
그러나 이런 개연성에도 보는 재미는 훌륭했습니다. 과학적으로 말이 안되는 그림이라고 들었지만, 중력에 의해 발생하는 장면들이 꽤나 흥미를 자아냈어요. 하지만 실제로도 이럴까 싶었던 내용이 과학적 원리에는 맞지 않는다는 사실이 아쉬웠지만, 그럼에도 재밌는 장면을 많이 볼 수 있었습니다.
그러나 스토리에서는 많이 아쉬웠습니다. 뜬금없는 전개, 억지 감동이 아쉬웠고, 재난 앞에서 진실은 오히려 감추는게 더 재난을 오롯이 받아들일 수 있지 않았을까 하는 아쉬움이 남습니다.
오랜만에 인사드립니다. 이번에는 오랜만에 영화관에서 평일(!) 영화나들이를 다녀오며 언차티드를 관람하게 되었습니다. 게임 원작의 영화라 이전에 보았던 월드오브워크래프트(평은 안좋았지만 저는 재미있게 관람하였습니다) 가 생각나며 큰 기대를 가지고 보게 된 영화였습니다.
언차티드 포스터
저에겐 톰 홀랜드 배우가 '스파이더맨' 역할을 맡지 않은 처음 작품이였습니다. 그래서 톰홀랜드의 연기도 정말 기대하며 관람하였습니다.
언차티드라는 게임을 플레이해본 적은 없지만, 영화를 보며 언차티드가 어드벤처 게임이 아닐까 하는 느낌과, 영화를 보면서 인디아나 존스가 생각나는 어드벤처물이라는 느낌이 강했습니다. 보물을 찾아 떠나며, 그안에서 배신과 협력이 겹치는 느낌이였습니다.
영화가 진행될 때 각종 수수께끼를 푸는 듯한 느낌, 그리고 시원한 액션과 그림은 재밌었지만, 톰홀랜드는 스파이더맨이 언차티드에 출연하는 느낌, 스파이더맨의 강렬한 색채를 지우기에는 역부족이란 느낌이였고, 어디선가 몰입이 방해되는 느낌이 들어 다른 어드벤처 프랜차이즈 영화에 비해 몰입이 안되는 느낌을 받아 살짝 아쉬운 느낌을 지울 수 없었습니다.
그래도 오랜만에 2시간을 시원한 액션으로 보낼 수 있어 즐거운 시간이였습니다. 오늘도 한줄평으로 마무리하겠습니다.
오랜만에 MySQL 인터널에 대해 정리해보겠습니다. MySQL의 메모리 구조 중, Change buffer입니다. 먼저, 이에 대한 더 자세한 내용은 아래 문서를 통해 자세히 확인하실 수 있습니다.
체인지 버퍼 개요
체인지 버퍼는 세컨더리 인덱스 페이지들의 변화를 캐시하는 메모리 영역인데요 이는 해당 페이지들이 버퍼풀에 있지 않을 때 사용되고, 이는 만약 쿼리에서 DML을 수행한 경우, 세컨더리 인덱스의 변경을 저장하여 이를 향후 정기적으로 머지하고, 페이지가 버퍼풀로 읽기 작업에 의해 로드될 때 머지됩니다.
즉, 세컨더리 인덱스와 관련된 데이터페이지가 버퍼풀에 없을 경우에는 변화는 체인지 버퍼에만 저장되고, 만약 해당 인덱스 페이지가 체인지 버퍼에 있을 때, 페이지에 있는 데이터가 체인지버퍼로부터 버퍼 풀로 적용(머지) 됩니다.
그리고 퍼지 작업을 통하여 세컨더리인덱스의 변화가 디스크로 적혀집니다. 이는 보통 idle, slow shultdown 등의 작업에 일어납니다. 이로 인하여 디스크 IO를 효율적으로 가져갈 수 있는 것이죠.
이 체인지 버퍼는 유니크 키에서는 사용되지 않으며, 몇가지 변수를 통하여 설정 가능합니다.
관련 변수값 설정
innodb_change_buffer 변수의 값은 아래와 같습니다.
all : 기본값으로, 버퍼 insert, delete-marking, purge 작업을 모두 수행합니다.
none : 체인지 버퍼작업을 진행하지 않습니다.
inserts : 인서트 작업을 버퍼합니다.
deletes : delete-marking 작업을 버퍼합니다.
changes : insert, delete-marking 작업을 버퍼합니다.
purges : 백그라운드에서 진행되는 물리 삭제 작업을 버퍼합니다.
이에 대한 버퍼값을 innodb_change_buffer_max_size 변수를 통하여 최댓값을 정할 수 있으며, 기본값을 25퍼센트이고 최대 50%까지 설정하실 수 있습니다. 이는 높은 DML 오퍼레이션 작업에서 해당 값을 높이기를 고려하실 수 있습니다. 이와 반대로 정적으로 데이터를 사용하거나, 체인지 버퍼가 메모리 영역을 너무많이 사용하는 경우 줄일 수있습니다.
체인지 버퍼 모니터링
체인지 버퍼는 SHOW ENGINE INNODB STATUS 명령의 출력밧을 통하여 모니터링할 수 있으며, INSERT BUFFER AND ADAPTIVE HASHINDEX 섹션을 통해 확인하실 수 있습니다. 또한 아래 명령을 통해서도 관련 지표를 모니터링하실 수 있습니다.
내용은 이랬습니다. 알수없는 현상이 발생하고, 기괴한 얼굴이 나와 '00일/시/분 뒤에 너는 지옥에 간다' 라는 내용을 들은 자는 해당 시간에 무언가가 나타나 예정된 시간에 죽음으로 몰고가고, 이 현상에 대한 사람들의 대처를 다룬 내용입니다.
1부는 이 현상에 대한 사람들의 대처, 그리고 이를 이용해 더 나은 세상을 만들려고 하는 왜곡된 사상을 가진 이의 성공을 들여다 봤다면, 2부는 이 성공을 무너뜨리는 내용이였죠.
1부에서 현상이 신흥 종교를 만들기 아주 좋은 형태로 나타났고, 이를 이용해 대중의 관심을 끌어내 사람을 선동하는데 성공한 정진수는 본인 또한 고지를 통해 죽게되지만, 결국 본인이 원하는 '나쁜 일을 하면 지옥에 간다' 라는 생각을 많은 사람에게 심어주고, 이것이 세상을 더 좋게 만들어준다는 신념을 가지고 있었죠.
처음 위 내용이 나오기 전 1부의 내용은 독자들이 작중의 죽음 현상이 죄를 지어야만 발생하는 현상으로 이해하도록 몰고 갔고, 이에 대한 반전이 1부 마지막에 나오는 형태였습니다. 그리고 해당 현상의 상징은 1부 중간, 정진수와 민혜진의 대화 사이에 나온다고 생각했어요.
바로 고대 제사장의 얘기였는데요, 이해할 수 없는 현상인 일식에 대한 고대 제사장과 사냥꾼의 행동에 대한 설명이였고, 여기서 경찰은 일식을 막기 위해 동원되는 사냥꾼에 묘사되고, 정진수는 제사장에 묘사되죠.
결국 이 작품이 얘기하는 내용은, "이해할 수 없는 현상의 발생을 현대인들이 어떻게 해석할 것인가" 로 보았습니다.
정진수는 이를 영리하게 자신이 원하는 이상의 세계를 만들고, 이를 통제하기 위한 '새진리회'를 만드는 데 이용하고자 하였고, 다음 교주인 김정칠은 이를 이용해 막대한 권력, 부를 가지는데 집중하죠.
그리고 민혜진과 '소도' 일당은 이에 대한 진실을 마주한 뒤, 이를 누구나 겪을 수 있는 불행한 재해로 묘사했구요.
그래서 죄가 없는 사람이 '고지'(죽음 현상을 고지라 새로운 종교집단인 새진리회가 명명합니다.) 및 시연을 당하는 모습을 생중계하여 이 현상은 죄와 전혀 관련이 없는 '재해'라는 진실을 알리려 노력합니다.
이는 결국 성공하는 것으로 마무리되며 부활하는 사람도 있다는 떡밥과 함께 극은 마쳐집니다.
시리즈를 보면서 매우 아쉬웠던 점은, 현상이 너무나 인간 친화적이라, 재해라 생각할 명분이 하나도 없단 것입니다. 이는 계속 극의 몰입을 방해하게 하였고, 시청자에게 이 현상에 대한 원인을 집중하게 만드는 결과를 낳았죠. 결국, 현상에 대한 설명이 없는 것이 일부 시청자에게는 불쾌하게 다가올 수 있는 현상이였단 것이죠. 알 수 없는 현상에 의해 사람이 죽는 재해는 다른 현상으로도 설명할 수 있고, 이를 개인의 야욕? 세계를 더 깨끗하게 만들겠다는 바람?(데스노트의 라이토가 생각나네요) 으로 해당 내용을 풀어나갈 수 있으리라 생각하는데, 전세계인이 죽게 되는 '고지'와 '시연'을 조금 더 납득할 수 있도록 만들었으면 어땠을까 하는 아쉬움이 남는 대목입니다.
그럼에도 알 수 없는 현상을 이용'만' 하는 자, 이용하여 더 나은 세상을 만들려는 자, 진실을 알리는 것이 더 나은 선택임을 알리려는 자 등 다양한 인간군상의 이해관계를 엿볼 수 있어 정말 흥미롭게 시간가는 줄 모르고 시청했습니다.
이에 추가적으로, 음악이 특히 마음에 들더라구요. 제목 '지옥'에 어울리는 음산하고 무서운 음악이 극에 더 집중할 수 있는 원동력을 심어주었습니다. 오징어 게임에 이어 다시한번 월드 랭킹 1위에 오른 한국 작품이라고 하던데, 더더욱 히트하여 한류 컨텐츠의 다양성에 이바지하는 작품이 되었으면 좋겠습니다.
인종 / 사랑 / 장애를 넘어 모든 이들이 출연하여 만들어내는 영화를 보며, 다양성은 자연스러운 것으로 표현하는 것이 굉장히 좋았습니다.
또한 중간중간 표현되는 이전 작품들의 언급도 좋았습니다. 이 부분에 대해 MCU 를 즐기지 않는 친구와 영활르 함께 보게 되어, 영화를 본 감상과, 다음에도 MCU 영화를 즐길 수 있을지에 대해 질문해보았는데요, 의외로 관련하여 이전 페이즈의 MCU언급때문에 보는데 이해하지 못하는 부분은 많이 없었고, '이터널스' 시리즈의 경우 속편이 나올 경우 볼 수도 있겠다는 얘기를 들었습니다.
마블의 다음 고민 중 하나인 '시리즈가 길어지면서 진입장벽이 높아지는 문제' 는 잘 해결해나가고 있다고 생각들었습니다.
그리고 쿠키의 경우도 기다리는 시간이 더 짧아지도록 엔딩 크래딧이 짧아진 것 같은 체감(진실은 아닐 수 있습니다.)이 들어 기다림에 부담이 없었구요.
여전히 좋은 영상미와 거대한 스케일을 보여주는 영화였다고 생각합니다. 전개 과정에서 집중하지 않으면 놓칠 수 있는 난해함은 있었지만, 다양성이 거부감없이(강요당한느 느낌 없이) 자연스럽게 표현되어 만족스러웠습니다.
오늘은 우리나라에서 크게 흥행하지 못했지만, 제게는 큰 울림을 줬던 영화, 라스트 듀얼에 대해 리뷰해보려고합니다.
라스트듀얼 포스터
우리나라에선 흥행하지 못했지만, 다른 나라에서는 박스오피스 1위를 차지하기도 했었고, 우리에게 익숙한 배우인 맷 데이먼과 벤 애플렉이 출연하기도 합니다.
사실 이터널스가 개봉한줄 알고, 약속을 잡았으나, 실은 이번주에 개봉한다는 소식을 듣고 개봉한 영화 중 하나를 고르게 되었는데요, 저는 계획없이 본 영화는 감병받는 법칙이라도 있나봅니다. 같이 본 친구의 말대로, 중세시대를 엿볼 수 있는 재밌는 영화였어요.
영화의 제목인 '라스트 듀얼' 은 역사상 마지막으로 공인된 결투 재판을 다루었는데요, 이 결투 재판의 계기가 참 흥미롭고, 다들 입장이 다릅니다. 각자의 주장이 다른 장면을 세명의 주인공의 시점에서 바라보는데요, 이때마다 실제 그들이 어떤 생각을 했는지 알 수 있었습니다.
각자의 주장을 엿보며, 저희는 점점 진실에 다가가게 되는데요, 그와중에 각자의 시선대로 각색된 모습이나, 당시에 여성을 인격체가 아닌 남성의 '소유물'로 인식하는 풍조, 그리고 아무도 진실을 믿지 않아 고통받는 여주인공까지, 중세시대의 어두운 점만을 낱낱이 보여줬습니다. 이 영화또한 디즈니에서 배급했지만, 제가 디즈니에서 보던 중세 왕자, 공주의 행복한 삶, 기사의 꿈과 희망이 넘치는 모험은 여기에는 없었죠. 상당히 날것에 가깝게 표현되는 중세시대의 묘사에, 저는 개인적으로 '저 시대에 가면 절대로 살지 못하겠다' 라는 생각이 들더라구요.
장 드 카르주는 자신의 명예와 친구로부터 잃어버린 재산을 돌려받는 목적, 자크 르 그리는 욕정에 눈이 멀었다가 자신의 명예를 실추하기 싫어 결투를 진행하게 되고, 오로지 여주인공인 마르그리트만이 자신의 진실을 위해 싸우는데요, 결투 재판의 본의미를 모르다가, 알게 된 후 마르그리트가 얘기하는 대사는 많은 생각을 하게 만들었습니다. 이 재판에서 패배하게 될 경우, 자신은 산채로 화형당한다는 사실을 몰랐다가 몰랐 마르그리트는, 이 사실을 알게 된 이후 장 드 카르주에게 아래와 같이 말했습니다.
이 아이에겐 엄마가 필요해요, 엄마가 잃은 명예를 되찾고 싶은 것보다 더.
이미 결투 재판은 진행되기로 결정되었지만, 여기서 여성이 아이를 위해서, 그리고 시대의 배경상 얼마나 많은 것을 희생하며 지내왔는지 알 수 있는 대목이였죠. 결국 마지막으로 벌어진 결투 재판은 진실이 승리하는 모습으로 종료됩니다. 실화를 바탕으로, 그리고 중세시대의 남성위주의 권력구조, 그와중에 핍박받는 여성, 그리고 현실을 적나라하게 묘사했습니다.
현실은 차갑고 냉혹했다 라는 것을 알게 되는 영화였습니다. 중새시대의 현실을 그대로 엿보고온거같은 느낌을 받았던, 아주 인상적인 영화였습니다. 중세시대의 차가운 현실을 살펴보고 싶으신 분들께는 한번정도는 추천하는 영화입니다.
지금까지 대담이였습니다! 그럼 오늘도 즐거운 저녁 되시길 바라며 리뷰는 여기서 마치겠습니다!
앞서 안내드렸던 MySQL 아키텍쳐에서 보듯이, MySQL은 여러가지의 스토리지 엔진을 채택하여 테이블을 생성할 수 있습니다. 이를 통해 사용자는 목적에 맞는 특화된 스토리지 엔진을 사용할 수도 있는 구조입니다. 아래에 간단한 예시를 들어드리겠습니다.
사용자가 캐시용도의 테이블을 운영하고 싶을 때(데이터가 날아가도 문제 없으나 빨라야함) : MEMORY
로깅 형태의 데이터 저장을 원하는 경우 (트랜잭션은 필요하지 않고 입력속도가 빨라야 함 ) : MyISAM
RDBMS의 기본인 트랜잭션을 지원해야하고, 장애에 내구성이 강해야하는 일반적인 경우 : InnoDB
클러스터 구성을 통하여 쓰기 분산등의 이점을 얻고 싶은 경우 : NDBCluster
정도로 앞선 네개 엔진의 특성을 설명 드릴 수 있고, 추가로 사용자가 원하는 스토리지 엔진을 찾아 설치할 수도있습니다.
이중, 가장 일반적으로, 그리고 재해에 강한 RDBMS의 특성을 가장 잘 반영하는 스토리지 엔진은 InnoDB라고 볼 수 있겠네요. 오늘은 이에 대해 정리를 해드리겠습니다!
먼저 InnoDB의 특장점부터 설명드리자면 아래와 같습니다 😁
트랜잭션을 지원합니다(ACID 지원) -> 어찌보면 다른 DBMS에서는 당연히 지원해야하는 것일 수 있겠지만, MySQL의 다른 스토리지 엔진은 성능 등 다른 이유로 트랜잭션을 지원하지 않는 경우가 있습니다. 그러므로 RDBMS의 가장 기본적 특성인 트랜잭션을 지원한다는 것은 아주 매력적인 부분입니다.
Row-level 잠금을 지원합니다 -> 잠금을 위하여, Row 단위의 잠금을 사용하므로 DML의 동시성을 늘릴 수 있습니다.
Primary Key 위주의 정렬로 Primary Key 기준의 쿼리 수행시 가장 최적화된 쿼리를 수행 가능합니다. 이에 대해서는 차후 클러스터드 인덱스 항목을 통하여 더 자세히 구조에 대해 다뤄보겠습니다.
데이터 정합성을 보장하기 위하여 외래키 기능을 지원합니다.
기본적으로 읽기시, 잠금 없는 일관된 읽기를 지원합니다. MVCC, 혹은 버전 컨트롤이라 불리는 이 내용에 대해서는 차후 더 자세히 다루도록 하겠습니다.
오늘은 여기서, InnoDB의 메모리 구조에 대해 안내드리려고 합니다.
InnoDB Buffer pool
먼저 InnoDB의 메모리 구조를 안내드리기 위해선, 일반적으로 MySQL 메모리의 가장 큰 부분을 차지하는 버퍼풀을 빼놓고 얘기할 수 없습니다. 일반적인 목적으로 사용하는 MySQL의 경우, 만약 다른 어플리케이션이 수행되지 않는 DB 전용 서버의 경우, 버퍼 풀의 사이즈를 전체 메모리 용량의 3/4 까지도 잡아서 사용합니다.
여기에는 사용자가 접근한 테이블과 인덱스 데이터가 저장됩니다. 그리고 앞선 SELECT 수행절차에서 말씀드렸던(https://daedamee.tistory.com/entry/MySQL-Internal-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0-SELECT-%EC%88%98%ED%96%89%EA%B3%BC%EC%A0%95?category=727646) 메모리에 항상 올리고 시작하는 개념이 이 버퍼풀이라고 생각하시면 더 편하시겠죠? 😃
메모리 영역이 디스크보다 크다면 모든 데이터를 항상 메모리에 들고있을 수있어 굉장히 쾌적하게 이용할 수 있겠지만, 우리모두가 알고있듯 램은 비싸고 디스크는 저렴합니다. 그러므로 제한된 메모리를 효율적으로 사용하기 위해 InnoDB에서는 Least recently used (LRU) 알고리즘을 사용합니다. 자주 접근하는 데이터는 밀리지 않도록 앞으로 당기고, 자주 사용되지 않는 데이터는 메모리에서 제거하는(eviction이라고 부릅니다) 우선순위에 두는 방식으로 운영됩니다.
Innodb 버퍼풀 LRU 리스트 설명 페이지입니다.
기본적으로 버퍼풀의 3/8은 old sublist로 분류되며(밀려날 수 있는 페이지들), 나머지는 new list로, 그리고 그 사이를 midpoint로 부릅니다. old list의 페이지를 읽게 된다면 이는 다시 new list로 바뀌게 되며, 사용자의 요청으로 읽히게 되도 이 페이지는 new list로 가게 됩니다. 데이터베이스가 운영될때, 버퍼풀의 페이지는 "나이" 에 의해 움직이진 않습니다.
그리고 이에 대한 모니터링은 SHOW ENGINE INNODB STATUS; 명령을 통해 가능한데요, 아래 코드에서 간단히 설명드리겠습니다.
mysql> SHOW ENGINE INNODB STATUS\G
*************************** 1. row ***************************
.....
----------------------
BUFFER POOL AND MEMORY -- 버퍼풀 메모리 영역의 설명입니다. 사용하지 않는 곳이라 아주 깨끗하네요 :)
----------------------
Total large memory allocated 0 -- 버퍼풀에 얼마나 많은 메모리가 할당되었는지 나타냅니다.
Dictionary memory allocated 366605 -- InnoDB 데이터 딕셔너리가 얼마나 할당되어있는지 나타냅니다.
Buffer pool size 8192 -- 버퍼풀에 할당된 페이지의 사이즈입니다.
Free buffers 7061 -- 버퍼풀에 할단된 페이지 중, free 한 사이즈입니다.
Database pages 1127 -- 버퍼풀 LRU 리스트의 페이지의 사이즈입니다.
Old database pages 436 -- LRU Old 서브리스트에 있는 페이지의 사이즈입니다.
Modified db pages 0 -- 버퍼풀에서 변경된 페이지의 현재 숫자입니다.
Pending reads 0 -- 버퍼풀에서 읽기를 대기하는 페이지의 숫자입니다.
Pending writes: LRU 0, flush list 0, single page 0 -- 쓰기를 대기하는 페이지로, LRU의 경우 더티페이지를, flush의 경우 체크보인팅을, single의 경우 독립 페이지를 의미합니다.
Pages made young 0, not young 0 -- LRU리스트에서 young으로 만들어지는 페이지와 이게 아닌 페이지입니다.
0.00 youngs/s, 0.00 non-youngs/s
Pages read 985, created 142, written 158 -- 버퍼풀에서 읽히고/만들어지고/쓰인 페이지 숫자입니다.
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 1127, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)
mysql>
이상, 버퍼풀에 대해서 간단히 구조에 대해 공식 문서 및 간단한 명령을 통해 알아보았습니다!
MySQL에서 메모리의 용량이 데이터베이스에 어떤 영향을 미치는지, 그리고 자주 액세스하는 데이터가 왜 빠르게 리턴하는지에 대해 알 수 있는 시간이 되었네요!
긴 글 읽어주셔서 감사드리며, 다음 문서를 통해 메모리 구조에 대해 남은 Change buffer, Adaptive Hash Index, Log Buffer에 대해서도 정리하는 시간을 가져보겠습니다.
1주일만에 인사드리네요. 😃 오늘은 인터널을 살펴보기 위해서 Recovery Startup 과정을 살펴보려 합니다!
이를 살펴보면서 MySQL이 어떻게 트랜잭션을 유지할 수 있는지, 그리고 데이터 유실을 방지하기 위해 어떤 과정으로 쿼리가 수행되는지 볼 수 있을것으로 보이네요 :) 그럼 바로 시작해보겠습니다!
먼저, 이전에 설치했던 서버를 이용하여 스타트업이 어떤 에러로그를 발생시키는지 살펴볼까요?
2021-10-23T11:29:02.239156Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.26) starting as process 3493
2021-10-23T11:29:02.290251Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2021-10-23T11:29:02.814050Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2021-10-23T11:29:03.175226Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1 is enabled for channel mysql_main
2021-10-23T11:29:03.175366Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1.1 is enabled for channel mysql_main
2021-10-23T11:29:03.178772Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2021-10-23T11:29:03.178959Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2021-10-23T11:29:03.242920Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2021-10-23T11:29:03.243089Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.26' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server - GPL.
이를 통해 알 수 있는 것은 MySQL 이 어떤 버전인지, 어떤 PID를 가지는지, 그리고 로컬 접속을 위한 소켓의 위치와 원격 접속을 위한 port 위치를 알 수 있네요.
여기서는 MySQL 의 시작과 관련하여 일반적인 수행뿐만이 아닌 Crash Recovery 과정까지 포함할 예정이기 때문에, 수동으로 crash를 발생시킨후 띄우는 에러로그까지 포함하겠습니다! kill -9 명령을 통해 킬 후 다시 mysqld를 기동하였을 때, 아래와 같은 에러로그가 포함되는 것을 확인할 수 있었습니다.
2021-10-23T11:54:03.077366Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.26) starting as process 4455
2021-10-23T11:54:03.089246Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2021-10-23T11:54:04.402779Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 92021-10-23T11:54:04.613362Z 0 [System] [MY-010229] [Server] Starting XA crash recovery...
10 11 122021-10-23T11:54:04.640950Z 0 [System] [MY-010232] [Server] XA crash recovery finished.
13 14 15 16 17 18 19 202021-10-23T11:54:04.725160Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1 is enabled for channel mysql_main
2021-10-23T11:54:04.725389Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1.1 is enabled for channel mysql_main
2021-10-23T11:54:04.726445Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2021-10-23T11:54:04.726699Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
21 22 23 242021-10-23T11:54:04.775302Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2021-10-23T11:54:04.775443Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.26' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server - GPL.
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
먼저 MySQL이 시작되기 위해서는, 설정 파일(/etc/my.cnf - 설치 형식/OS에 따라 달라질 수 있습니다.)에 존재하는 설정에 적절한 파일이 존재하고, 접근이 가능해야합니다. 기본적으로 basedir, datadir, socket 설정 등이 있겠습니다. 설정이 제대로 되어있다면, 데이터 파일을 살펴보게 됩니다. 데이터파일을 살펴보던 도중 데이터파일에 이슈가 있다면 이에 대한 자동 복구를 시작하게 되며 이때 recovery를 수행하게 됩니다.
리커버리는 아래와 같은 절차를 통해 수행되게 됩니다. 여기서는 MySQL에서 가장 많이 사용되는 InnoDB 스토리지 엔진에 대해서만 다루겠습니다.
테이블스페이스 찾기 : InnoDB가 리두 로그 적용이 필요한 테이블스페이스를 찾아내기 위해 사용되는 절차입니다.
리두로그 적용 : 초기화동안 리두로그 적용이 진행됩니다. 다른 커넥션들을 허용하기 전에, 모든 변경분이 버퍼풀로부터 테이블스페이스로 적용이 되어있다면(= 더티 페이지가 없다면) 해당 절차는 생략됩니다.
완료가 되지 않은 트랜잭션 롤백 : 완료가 되지않은 트랜잭션이란, 예상치 못한 크래시 이전에 활성화된 트랜잭션이나 Fast shutdown시 발견되는 트랜잭션을 의미합니다. 해당 작업들을 롤백하는 작업이 리두로그 적용 이후 적용됩니다.
날씨가 엄청 쌀쌀해지는 하루네요, 다들 추위에 대비하시어 두꺼운 옷을 꺼내셔서 건강하게 요즘 날씨 헤쳐나가면 좋겠습니다.
오늘 리뷰해드릴 영화는 최근 아주 몰입감있게 볼수 있어서 꼭! 소개해드리고 싶은 영화, '혼자 사는 사람들' 입니다.
혼자사는 사람들 포스터
2021년 5월에 개봉한 영화로, 최근 넷플릭스에서 확인하여 보게되었는데요, 공승연 배우님의 원탑 영화라고 할 수 있을 만큼 주인공 위주의 얘기로 흘러가는 영화입니다.
극중 주인공인 '진아' 는 감정이 메마른 삶을 살지만, 이와 다르게 감정을 엄청 소모하는 감정노동자인 카드사 콜센터 직원입니다. 카드사 직원으로써 엄청난 상을 받을 만큼 일을 잘 해내고 있지만, 옆집 남자의 갑작스런 죽음, 성격이 맞지 않는 신입사원 교육간의 마찰, 가족과의 갈등까지.. 진아를 앞두고 많은 사건이 극중에서 일어나게 되는데요, 이로 인해 변화하는 진아를 관찰하는 영화라는 느낌을 받았습니다.
영화를 보면서, 굉장히 몰입감이 강하게 들고, 현실을 아주 잘 반영했다는 생각이 들었습니다. 저같은 경우는 '회사'에서의 관계라는 가치를 다시한번 곱씹어보게 되었는데요, 점점 회식도 적어지고 회사에서의 사생활 존중, 그리고 회사의 일은 회사에서만 끝내는게 당연하지만, 이에 대한 반작용으로 진아와 같은 삶을 살게 된다면 이 또한 얼마나 무료할지 생각해보게 되었습니다.
진아는 극중 처음에는 본연의 업무를 굉장히 잘하지만, 업무의 특성상 동료와 얘기할 일도 없고, 고객과 얘기할 일은 많지만 이 업무 또한 굉장히 기계적으로 감정을 배제하고 처리하는데요, 제가 저렇게 주중의 1/3을 보낼 수 있을까? 하는 생각을 해보면 정말로 쉽지 않은 일이겠다는 생각이 들었습니다.
사실 지속 가능한 생활을 하기 위해서는 정신건강의 관리도 중요한 부분 중 하나라고 생각이 들었는데, 이부분을 상처받지 않기 위해 꽁꽁 싸매고 사는 진아의 모습을 보며, 이것이 맞나 라는 생각이 들었습니다. 진아같은 경우는 회사생활 외에 일상생활에서도 철저히 혼자만의 삶을 영위하는 캐릭터로 나와, 1인가구의 현실을 잘 보여주는 캐릭터라는 생각이 들더라구요.
이를 통해 1인 가구로써의 삶을 풍요롭게 하는법, 회사생활에서 적당한 관계를 유지하며 정신건강 관리를 하는 법, 그리고 특히나, 자신을 잘 돌아보는 법에 대해 다시한번 고민하게 되는 좋은 영화였습니다.
요즘 세대를 들여다보고 싶거나, 요즘 1인가구의 삶을 엿보고 싶은 분들께는 강력 추천하는 영화입니다.
