'분류 전체보기'에 해당되는 글 380건

주식으로 큰 돈을 번 사람들은 어떤 사람들일까?
생각해보면 정말 사고팔고 등을 잘해서 벌었다는 경우는 거의없고

일반인 중에서는 전원주씨처럼 갈만한 주식을 10~20년간 존버... 를 해서; 이거는 정말 쉽지않다.

보통은 주식으로 큰돈을 번 경우는 별로 없다.
하지만 비상장주식을 가지고 있던 사람이 기업이 주식을 상장(IPO)하고 큰 돈을 번 경우는 많이 봤다.

* SK바이오팜 직원들, 상장 하루만에 1인당 9억을 벌었다.

biz.chosun.com/site/data/html_dir/2020/07/02/2020070202775.html

IPO 란?
IPO(Initial Public Offering)란 비상장기업이 정해진 절차에 따라 일반 불특정 다수의 투자자들에게 
새로 주식을 발행하거나 기존 주식을 매출하여 유가증권시장 또는 코스닥시장에 상장하는 행위를 말합니다.

이처럼 될만한 코인을 먼저 선점해서 가지고 있다가 거래소에 상장되면 큰 수익을 얻을 수 있을지도 모르겠다는

생각이 들었다. 코인에서는 거래소에 상장되지 않는 코인들을 살 수 있는 곳이 없을까?

찾아보니 살수 있는 곳이 있었다. 오호!
유니스왑(uniswap)이라는 곳에서 거래소에 상장되지 않은 코인을 매수할 수 있었다.

-그렇지 이거야... 여기서 제2의 비트코인을 찾아 미리선점한다면?ㅎㅎ

그건 그렇고 일단 한번해볼까?
어? 근데 메타마스크 지갑을 설치해야한다는 얘기가 있다. 이건 또 뭐냐.. 머리가 아프다.

메타마스크 란?
- 메타마스크는 이더리움 계열의 코인들을 편리하고 안전하게 보관할 수 있는 암호화폐 지갑입니다. 미국의 컨센시스 회사가 개발 및 관리하고 있습니다. 구글 확장 프로그램과 모바일 어플을 서비스중이며 메타마스크를 활용하면 이더리움 계열토큰을 송금할 수 있습니다.
최근에는 UNISwap과 같은 곳에서 유동성을 제공하여 채굴등을 하는데 더욱 많이 쓰이는 중입니다.

그럼 이것 먼저 설치해본다.

다운로드주소: metamask.io/download.html

1) Install MetaMask for Chrome 클릭!

2) Chrome에 추가 클릭!

3) 시작하기 클릭!

4) 처음 만드는 거니까 지갑생성 클릭!

5) 동의함 클릭!

6) 지갑에 사용할 암호를 만들고 마지막에 생성 클릭!

7) (암호를 표시하려면 여기를 클릭하세요) 클릭! 해서 비밀번호를 파일(.txt)로 따로 보관해놓는다. 그후 다음 클릭!

8) 아까 저장해두었던 파일을 열어서 단어를 순서대로 클릭! 한다.

9) 설치가 모두 끝났고 구문을 잊어버리거나 공유하지 말라고 얘기하고 있다. 
- 이것에 대해 중요성을 생각해보면 (신용카드번호+비밀번호)라고 보면 될 듯하다. 털리면 끝이니까 따로 안전하게 보관하자

11) 정상적으로 설치되면 아래와 같다.

12) 토큰추가

유니스왑을 연동 전에 이더리움 계열 토큰을 추가해야한다.

(이게 무슨말이냐하면 내가 어떤 암호화폐를 거래소에서 메타마스크(지갑)으로 가져왔는데 안보일 수가 있다

지갑에 토큰 주소가 등록되어있어야 바로 확인이 가능하다.)

여러토큰(암호화폐) 중에 사용할 것을 추가해준다.
방법은 검색하는 것과 실제 토큰주소를 넣어주는 방법이 있는데 맞춤형 토큰 방법을 추천한다.

토큰의 계약주소를 확인하는 방법은 아래 접속한다

etherscan.io/tokens

1) 토큰의 계약주소찾기
위에 보이는 화면에서 토큰명을 입력한후 검색을 하면 아래 보이는 화면처럼 토큰명및 컨트랙트 주소를 확인할 수 있다

2) 토큰의 계약주소찾기

13) 나는 DAI 라는 것을 추가해본다. 

- DAI는 현재기준 1달러와 동일한 가치를 지닌 암호화폐이다. 처음에 DAI라는 존재에 대해 알고 깜짝 놀랐다. 

암호화폐는 언제든 100만원이 1원이 될 수 있는 믿을 수 없고 변동이 큰 자산이라고 생각했는데..
암호화폐도 이제는 DAI 같이 변하지 않는 고정적인 자산을 만들어놓고 거기에 여러 화폐를 SWAP(교환)할 수 있도록 만들어 놓았다.

오호.. 이거 공부하는 재미가 있다...이곳은 앞으로 머지않아 어쩔수 없이 전세계가 인정하는 또 하나의 주식거래소와 같은 시장이 열릴 수 밖에 없을 듯하다.

14) 토큰 추가하게되면 아까는 이더리움밖에 안보였는데 DAI가 추가된 것을 확인할 수 있다.

후.. 이제 UNISWAP을 연결해볼까?

1부 끝.

xtrabackup 후 restore하면서 로그를 보고있는데 *.TRG로 끝나는 파일이 있다.
생소한데;... 뭔가 한번 확인해 보았다.

TRG 파일은?

트리거 관련 파일을 말한다.
트리거 파일은 확장자가 trg가 되며 트리거 명.trg가 아니라, 트리거가 생성되어 있는 테이블명.trg가 생성된다.
해당 테이블에 트리거가 많을 경우 하나의 trg파일에 모두 저장되고, 트리거명.trn 파일이 생성된다.

1) restore 후 실제파일 확인

[root@test-db xxxDB]# ls -al *.TRG
-rw-r----- 1 root root 9509 2021-03-23 06:04 TB_xxx.TRG
-rw-r----- 1 root root 5450 2021-03-23 06:04 TB_xxx_TC.TRG
// trg파일은 트리거를 사용하는 테이블명.trg로 생성되어 있다.

[root@test-db xxxDB]# ls -al *.TRN
-rw-r----- 1 root root 42 2021-03-23 06:04 TB_xxx_AFTER_INSERT.TRN
-rw-r----- 1 root root 42 2021-03-23 06:04 TB_xxx_AFTER_UPDATE.TRN
-rw-r----- 1 root root 46 2021-03-23 06:04 TB_xxx__TC_AFTER_INSERT.TRN
-rw-r----- 1 root root 46 2021-03-23 06:04 TB_xxx__TC_AFTER_UPDATE.TRN
// 실제 트리거는 .trn으로 생성되어있다.

2) mysql 8에서 달라지는 점
data dictionary를 사용하면서 기존에 파일로 있었던 .frm / .par / .trn / .trg 등의 파일이 사라진다.
mysql 데이터베이스의 데이터들은 mysql.ibd 테이블 스페이스에 저장이 된다고 합니다.

 - mysql 8에서는 데이터사전이란 개념이 들어가면서 mysql.ibd로 통합되고 .trg는 더이상 사용하지 않는다고 한다.

mysql 데이터베이스의 테이블들을 show create table 명령으로 확인해 보면 아래와 같습니다.
/*!50100 TABLESPACE `mysql` */ ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0
더이상 MyISAM 엔진을 사용하지 않습니다.

InnoDB 엔진 이외의 엔진들에 대한 metadata 저장은 Serialized Dictionary Information (SDI) 파일에 JSON으로 저장합니다. 기본 설치후에 mysql 데이터베이스 디렉토리에 general_log와 slow_log 테이블의 .sdi 파일을 확인할 수 있습니다.

요즘은 시중에 돈이 많이 풀리고 부동산, 주식등 재태크 열풍이다.
근데 나는 돈이 없다;
그래서 재태크를 할 여러방법을 궁리하다.. 예전에 잠깐 열풍이 불었던 암호화폐가 요즘 다시 빛을 본다는 기사를 

보고 한번 확인해보았다.

음...?
2017~2018년 급락이후 수많은 사람들의 눈물 흘리게 했던 비트코인이 다시 상승하고 있었다.

국민코인이라는 리플(XRP)도 에어드랍 이슈후 가격이 상승하고 있다.

*에어드랍이란?
에어드랍(Air Drop)은 사전적인 의미는 말 그대로 공중 투하입니다. 배틀그라운드라는 생존게임에서 항공기나 낙하산으로 식량이나 무기등을 공중에서 떨어트리는 것과 같습니다. 주식으로 치면 무상증자와 같은 개념입니다.
코인에서 에어드랍은 거래소에서 마케팅 수단으로 주거나 재단에서 기존코인의 하드포크로 인해 코인이 둘로 나눴을 경우 (비트코인캐시와 비트코인골드는 비트코인에서 하드포크로 생겼고 지지자들은 비트코인과 동등 수량의 코인을 받았습니다) 동일 수량 지급되는 경우가 있습니다.
이처럼 에어드랍은 무상 지급이긴 하나, 새로 생긴 코인에 대한 홍보와 사용자 확보를 하여 거래량을 늘리기 위해 시행됩니다. 즉 마케팅 전략으로 보시면 됩니다.
보통 에어드랍은 호재로 받아들여져서 기존코인과 새로생긴 코인의 가치가 함께 급등하는 경우가 많습니다

암호화폐를 했는 사람이라면 리플에 사연없는 사람 별로 없을 것이다.

한 때 이런짤이 돌아다니곤 했었다.^^;;

하지만 요즘 시중에 돈이 많이 풀렸다더니 확실히 암호화폐시장도 다시 호황인듯하다.
근데 나는 투자할 돈은 없고...뭐라도 해보고 싶은데;
요즘 직접투자하는 방법도 있지만 바야흐로 디파이 시대라는 얘기가 있어 확인해보니 비트코인같이 일종의 채굴하는 시스템인데  모바일로도 하는 간단한 방법이 있다고 해서 한번 도전해보기로 했다.

가장 많이 하는 파이코인 ? 이라는 건데 일단 홈페이지를 가본다.

minepi.com/choiyh22

SCP 프로토콜 어쩌고 하는데 어려워서 잘모르겠다. 비트코인처럼 어려운 수학연산을 푸는 건 아닌거 같고
앱을 굳이 켜지 않고 하루에 한번만 업데이트해주면 코인을 시간당 일정 보상해주겠다는 얘기이다.
많은 사람들이 이미 하고 있다니까 한번 설치해볼까?

설치 1

1) 모바일 앱에서 파이코인 을 검색 후 설치
2) 인증하는데 페이스북인증하고 전화번호 인증이 있는데, 나중에 시간이지나면 2차인증을 하고 '방패' 라는 것을 추가로 하게되면 채굴속도가 더 빨라지는데 전화번호 인증을 해야한다.
   귀찮으니까 처음부터 전화번호로 시작하는 것을 추천한다.

설치 2

3) 초대코드를 입력하는 부분이다. 이거 또 다단계네?ㅋ 그러면그렇지.. 싶어 
   걍 안하려고 했는데 검색해보니까 이 프로세스 자체가 많은 사람이 모여야 채굴속도가 빨라지는 구조이다.
   다른분꺼 넣어도 되고 없으면  choiyh22 넣어주시면 감사^^
   나중에 알게된건데 채굴속도를 높이려면 4일후에 처음 코드 넣은 사람 포함 총 5명만 모으면 된다

설치 3

4) 이제 번개마크를 클릭하면 상단에 채굴이 시작되고 추천코드를 넣었으면 1 파이를 얻고 시작하게 된다.


설치 4

5) 24시간마다 한번 알람이 오고 확인해서 번개모양만 한번씩 눌러주면 된다.

테스트해보니 하루에 2.5 파이정도 얻을 수 있을 거 같다. 
전화기가 꺼져도 파이의 숫자는 늘어나는 것으로 보아 이 코인은 디파이(채굴)라고 얘기하지만 비트코인처럼 뭔가를

계속 연산하는 것은 아니고

홈페이지에서 설명한대로 특정시점까지 user를 모으고 초기시점에 들어온 사람에게 일종의 benefit으로 기다려준

시간만큼 코인을 보상하는 그런 시스템 같다.
뭐 밑져야 본전이지.. 하루에 한번 하는건데 해볼만 할 거 같다.

비트코인도 상장 전에는 이렇게 크게 가치가 올라갈 것이라고 생각한 사람은 없었다.

*11년전 비트코인 1만개로 피자 2판 구매한 남성 인터뷰

www.insight.co.kr/news/320369

현재가치로 가치로 따지면 660억에 피자 2판을 먹은 것이다 ㅎㅎ

암호화폐는 아직 불확실한 시장이고 변동성이 많은 시장이다. 직접 자기자본을 들여 투자하기에 부담스럽다면
아직 거래소에 상장하지 않은 이런 코인을 미리 찾아 디파이(채굴)하는 것도 좋은 투자라고 생각한다.

끝.

참조 : kakao777.tistory.com/4427

6) The next story ( 그 이후로 이야기)

일단 초대코드 넣고 가입하신분 감사합니다. 확인하는대로 방패네트워크까지 미리 다 추가하였습니다.
3일뒤에 확인해서 0.1 추가 보안 배니핏 받으시길 바랍니다.

그리고 하다보면 아시겠지만 이게 초대인으로 연결된 다단계(?)라고 오해하기 쉬운데 중요한 건 실제 참여 회원입니다.
서로 하루에 한번씩 잊지 않고 번개를 눌러야 서로의 채굴속도가 높아지는 것이지 처음에 초대해서 한명 더 늘었다고 계속 채굴속도가 높아지지 않습니다.
괜히 자리만 차지할 뿐입니다.

Tip을 드리자면 주위에 관심있고 열심히 하실 분들끼리 모아서 하시는 게 잴 좋습니다.

그리고 파이 코인의 향후일정이 계속해서 업데이트 되고 있는데 정리하면

-----------------------------------------------------------------------------------
1) 이미 테스트 지갑이 나왔고 

2) 그 다음은 현재 채굴하는 파이를 블록체인, 실제 암호화폐로 교환하는 단계
3) 그리고 마지막 올해말 메인넷 출시입니다.(메인넷이 출시되어야 거래소 상장이 가능합니다.)
4) 여기까지가 끝나면 그 다음이 바로 거래소 상장입니다.
------------------------------------------------------------------------------------

파이 코인이 어떤 식으로 풀릴지 아직은 모릅니다.

기존 코인들처럼 개발자들이 몇 100만개씩 쌓아서 만들어 놓고 풀지

아니면 진짜 유저가 채굴한 코인만 가지고 유통이 될지 모릅니다.

전자는 대부분의 코인이 택하는 방식입니다.

전자로 간다면 아마도 초기 거래소 상장시엔 그렇게 큰 가치는 없을 거 같습니다.

근데 만약 후자로 간다고 하면, 유튜브에서 10만개이상 채굴한 유저 인증이 올라오긴 하지만

그들은 소수일 뿐입니다. 이걸 믿고 계속하는 사람은 많지 않습니다.

만약 유저가 채굴한 것만으로 거래소 상장을 한다면 거래소는 상장하기위해 코인을 미리 매수해야하고

거기서 이미 채굴량 대비 코인의 가치는 매겨집니다. 아무래도 비쌀 수 밖에 없겠죠?

중국에서 알음알음 거래한다는 1달러 설이 헛소문이 아닐 수도 있습니다.

하지만 어떻게 될지, 어떻게 풀릴지 모르니 내년을 보고 열심히 할 수 밖에 없겠죠^^

다들 하루에 한번씩 잊지말고 번개! 눌러주세요.

잠깐의 수고로움으로 큰 행운이 올지도 모르는 일입니다.

그럼 이만.

[ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
[ERROR] mysqld got signal 6 ;

DB는 얼마지나지 않아 다시 내려갔다.
눈앞이 캄캄해진다.
--> 며칠전에 오라클에서 마리아DB로 마이그레이션후 수많은 장애로 다시는 마리아DB를 쳐다보고 싶지 않다는 블로그에 글을 읽으며 속으로는 그러게 준비를 잘했어야지 RDB라고 다 같은 줄 아나? 라고 속으로 웃었는데.. 사람은 착하게 살아야; 막상 당해보니 너무 아프네

이제 방법은 2가지 문제를 해결하거나 아니면 MariaDB 10.2.15 로 롤백하는 방법뿐이다.
결정은 롤백에 소요되는 시간을 고려하면 남은시간은 15시간 뿐이다.

문뜩 그런생각이 들었다

이 일을 막을 수 있었나?
--> 막을 수 있었다. 서비스 DB와 동일한 환경에서 테스트를 더 했더라면 충분히 막을 수 있었다. 하지만 대용량DB라 그럴만한 서버가 없었다...아니다 그것을 설득하지 못한 DBA의 핑계일지도..

갑자기 요즘 즐겨보던 유튜브 중 한편이 생각난다.

www.youtube.com/watch?v=DsOUEAbzaIA

#경영효율화로 인한 희생 알래스카 항공 261편 ... 기장은 최선을 다했고 마지막까지 배면비행을 하며 사투를 벌였지만 살아남지 못했다... 나는 살아남을 수 있을까?

그냥그렇다.. 아무생각도 들지않고 멍하니 로그와 구글링 페이지만 30분째 보고 있었다.
하지만 시간은 한정되어 있고 그 시간안에 해결할 방법을 찾아야한다.

일단 정신차리고 error로그 먼저 확인해 본다.

2021-02-27  1:28:41 284 [ERROR] mysqld: Table './xxxDB/TB_STA_xxx' is marked as crashed and last (automatic?) repair failed
2021-02-27  1:28:41 284 [ERROR] mysqld: Table './xxxDB/TB_STA_xxxxx' is marked as crashed and last (automatic?) repair failed

DB는 재시작하면서 복구를 했지만 MyISAM 테이블이 일부가 깨졌다. 수동복구를 진행한다.

MariaDB [xxxDB]> check table TB_STA_xxx;
+------------------+-------+----------+-------------------------------------------------------+
| Table            | Op    | Msg_type | Msg_text                                              |
+--------------------------+----------+-------------------------------------------------------+
| xxxDB.TB_STA_xxx | check | warning  | Table is marked as crashed and last repair failed     |
| xxxDB.TB_STA_xxx | check | warning  | 1 client is using or hasn't closed the table properly |
| xxxDB.TB_STA_xxx | check | warning  | Size of indexfile is: 167163904      Should be: 1024  |
| xxxDB.TB_STA_xxx | check | error    | Record-count is not ok; is 3159708   Should be: 0     |
| xxxDB.TB_STA_xxx | check | warning  | Found 3159715 key parts. Should be: 0                 |
| xxxDB.TB_STA_xxx | check | error    | Corrupt                                               |
+--------------------------+----------+-------------------------------------------------------+
6 rows in set (7.935 sec)

MariaDB [xxxDB]> repair table TB_STA_xxx;
+------------------+--------+----------+------------------------------------------+
| Table            | Op     | Msg_type | Msg_text                                 |
+------------------+--------+----------+------------------------------------------+
| xxxDB.TB_STA_xxx | repair | warning  | Number of rows changed from 0 to 3159708 |
| xxxDB.TB_STA_xxx | repair | status   | OK                                       |
+------------------+--------+----------+------------------------------------------+
2 rows in set (22.793 sec)'

테이블 복구후 DB가 내려간 부분을 확인해본다.

1 lock struct(s), heap size 1128, 0 row lock(s), undo log entries 218
MySQL thread id 21136, OS thread handle 140521381996288, query id 12716892 172.31.8.77 mdlbat Sending data
SELECT COUNT(*) FROM TB_xxx    WHERE ..

카운트하는데 락이 생겼다? 뭔가 이상하다.

MetaLock을 확인해본다.

MariaDB [(none)]> SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
+-----------+-------------------------+---------------+----------------------+--------------+-----------------------+
| THREAD_ID | LOCK_MODE               | LOCK_DURATION | LOCK_TYPE            | TABLE_SCHEMA | TABLE_NAME            |
+-----------+-------------------------+---------------+----------------------+--------------+-----------------------+
|     44657 | xxx_BACKUP_DDL          | NULL          | Backup lock          |              |                       |
|     44657 | xxx_EXCLUSIVE           | NULL          | Table metadata lock  | xxxDB        | TB_TEMP_xxx 			|
|     44657 | xxx_INTENTION_EXCLUSIVE | NULL          | Schema metadata lock | xxxDB        |                       |
|     44657 | xxx_SHARED_READ         | NULL          | Table metadata lock  | xxxDB        | TB_TEMP_xxx		    |
|     44657 | xxx_SHARED_READ         | NULL          | Table metadata lock  | xxxDB        | TB_BAT_xxx      		|
+-----------+-------------------------+---------------+----------------------+--------------+-----------------------+

Schema metadata lock 이런 락은 처음보는데.. 뭔가 이상하다.
Tool로 접속해서 실제 테이블 데이터를 한번 봐야할 거 같다.

음?..Tool 자체 커넥션이 안된다. 다시 쉘로 돌아와서 보니 Meta LOCK이 잡혀있다.

| 45258 |  xxxxx   | 210.xxx.xxx.xxx:45944 | xxxDB | Query   |   29 | Waiting for table metadata lock | 
SELECT cc.CONSTRAINT_NAME, cc.CHECK_CLAUSE, tc.TABLE_NAME
FROM INFORMATION_SCHEMA.CHECK_CONSTRAINTS cc, INFORMATION_SCHEMA.TABLE_CONSTRAINTS tc
WHERE cc.CONSTRAINT_NAME = tc.CONSTRAINT_NAME
AND cc.CONSTRAINT_SCHEMA ='xxxDB' AND tc.TABLE_NAME='TB_TEMP_xxx'
ORDER BY cc.CONSTRAINT_NAME ;

뭔가 이상하다. Create table로 대용량테이블에서 인댁스 걸린 일데이터만 쪼개서 생성하는 로직인데, 
Tool에서 접속시 information 스키마부분을 조회한다고 Metalock이 잡혀 Tool 접속이 안된다는 것이.. 

MyISAM도 아니고.. InnoDB인데..
이 떄부터 MariaDB 10.4.17 자체 버그를 의심했다.

구글링하면서 MairDB를 업그레이드하고 동일한 현상의 문제를 겪은 사람들의 블로그를 하나둘씩 찾을 수 있었다.
innodb_purge_threads 를 1로 변경하면 임시조치로 DB가 재시작되는 것은 막을수 있다는 얘기가 있어
일단 반영해보기로 하였다.

MariaDB [(none)]> show global variables like  'innodb_purge%';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| innodb_purge_batch_size              | 300   |
| innodb_purge_rseg_truncate_frequency | 128   |
| innodb_purge_threads                 | 1     |
+--------------------------------------+-------+
3 rows in set (0.001 sec)

이제 끝났겠지라고 생각했지만 10시간후 DB는 재시작되었다.
이 방법은 아니다. 이제 남은시간은 4시간뿐;

MariaDB jira의 사례를 찾고 또 찾았다.

비슷한 사례의 글을 찾을 수 있었으나 해결했다는 글은 찾아볼 수 없었다. 

그러던 중 10.4.15에서 17로 올린 사람은 고통받다 롤백을 결정했다는 글에서 링크걸린 글을 찾다보니

10.4.14에서 17로 올리고 동일한 현상으로 고통받고 있는 사람의 글 맨아래 comment에서
10.5.8에서 10.5.9로 올리고 해결되었다는 글을 찾을 수 있었다. 10.5.9의 10.4.x 동일버전은 10.4.18이다.

jira.mariadb.org/browse/MDEV-24378

Comments: I have been using 10.5.8 ... the problem has been resolved after upgrading to 10.5.9

그렇다면 10.4.18로 올려볼만하다.
--> 하지만 이제 4시간밖에 남지 않았다. 한번 선택하면 끝이다. 

그리고 설득도 어려웠다. 업그레이드는 web/was를 내려야하기 때문에 윗선에 결제가 필요했다.

설득하고 또 설득했다. 롤백은 cold 백업후 중단시간이 길기 때문에 한번 해볼만한 시도라고...

(자세히 얘기하면 길어지고 설득하기 쉽지 않을 거 같아 간략하게 설명했지만

사실상 10.2.15로 롤백한다면 mariabackup shell도 xtrabackup으로 변경해야하고 redo log 파일변경부터해서, 10.3.x부터 mysql 부분 information 스키마, 계정관리등등..이 바뀌기 때문에 10.4.x의 mysql 스키마를 쓰지 못하고 이전 mysql 스키마만 다시 떠야하고.. 많이 복잡해진다.)

다행히 1시간만에  업그레이드가 결정되었고 내선택이 최선이길 바라며 MaiaDB 10.4.18로 업그레이드를 진행하였다.

mariadb.com/kb/en/mariadb-10418-release-notes/

Last month long-time MariaDB VP of Engineering, Rasmus Johansson, passed due to complications from cancer. 
His loss has been felt keenly by the whole MariaDB team. 
Our thoughts are with his family during this difficult time and this release is dedicated to his memory.
-->이번 release는 뭔가 좀 다르다. 마음이 먹먹해지는 글이다. 그를 위해 바치는 이 release가 나에게도 한줄기 빛이 되길 기대해본다 제발!!

[root@xxx-db bin]# service mysqld start
.......                                                    [  OK  ]

[admin@xxx-db bin]$ mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 20
Server version: 10.4.18-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show processlist;
+----+-------------+----------------------+-------+---------+------+--------------------------+------------------+----------+
| Id | User        | Host                 | db    | Command | Time | State                    | Info             | Progress |
+----+-------------+----------------------+-------+---------+------+--------------------------+------------------+----------+
|  4 | system user |                      | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|  2 | system user |                      | NULL  | Daemon  | NULL | InnoDB purge coordinator | NULL             |    0.000 |
|  1 | system user |                      | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|  3 | system user |                      | NULL  | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|  5 | system user |                      | NULL  | Daemon  | NULL | InnoDB shutdown handler  | NULL             |    0.000 |
...
| 20 | root        | localhost            | NULL  | Query   |    0 | Init                     | show processlist |    0.000 |
+----+-------------+----------------------+-------+---------+------+--------------------------+------------------+----------+
17 rows in set (0.000 sec)

MariaDB [(none)]> exit
Bye

//10.4.18로 바뀐거 확인하고 데이터 업그레이드 진행하였다.

[root@xxx-db bin]# ./mysql_upgrade -uroot -p
Enter password: 
Phase 1/7: Checking and upgrading mysql database
Processing databases
mysql
mysql.column_stats                                 OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.global_priv                                  OK
mysql.gtid_slave_pos                               OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.index_stats                                  OK
mysql.innodb_index_stats                           OK
mysql.innodb_table_stats                           OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.roles_mapping                                OK
mysql.servers                                      OK
mysql.table_stats                                  OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.transaction_registry                         OK
Phase 2/7: Installing used storage engines... Skipped
Phase 3/7: Fixing views
.....
information_schema
performance_schema
test
Phase 7/7: Running 'FLUSH PRIVILEGES'
OK

[root@xxx-db error]# service mysqld restart
Shutting down MariaDB..                                    [  OK  ]
Starting MariaDB.210227 14:39:24 mysqld_safe Logging to '/data/mariadb_logs/error/mysql.err'.
210227 14:39:24 mysqld_safe Starting mysqld daemon with databases from /data/mariadb_data
                                                           [  OK  ]

DB는 2021.3.15일 현재까지 정상적으로 잘 돌아가고 있다.
결과적으로 MariaDB 10.4.17 stable 버전을 설치했지만 자체버그이고

10.4.17을 10.4.18로 올리고 모든 문제는 해결되었다.
왜 무리하게 버전을 올리려고 했을까? 돌이켜 생각해보면 별도의 튜닝없이도 1시간 걸리는 배치가

40분내외로 줄어드는 성능향상을 확인했고, 
100개가 넘는 배치들과 현재DB의 수용능력이 포화상태라 생각해서 결정한 일이었는데, 

꼼꼼한 테스트를 하지 못해 악수가 되고 말았다.

DB 업그레이드는 많은 시간과 테스트를 해보고 좀 더 보수적으로 해야한다는 것을 다시한번 느끼게 해주는 경험이었다.
나의 주말은 2주째 치열했지만 누군가 MariaDB 업그레이드후 고통받고 있을 분에게 도움이 되길..

나는 살아남았다.

2차 대응 끝.

마리아 그녀를 믿지 마세요..

MariaDB 10.2.15 to 10.4.17 로 올린 후 DB가 shutdown 되고 있다.
정확하게 얘기하면 내려갔다 다시 올라오고 있다.

로그를 확인해보면 
[FATAL] InnoDB: Semaphore wait has lasted > 600 seconds 에러가 나고 자체적으로 복구하고 재시작을 하고 있다.

2021-02-19 11:47:06 153730 [Warning] Aborted connection 153730 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got timeout reading communication packets)
2021-02-19 11:47:07 153996 [Warning] Aborted connection 153996 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:07 153995 [Warning] Aborted connection 153995 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:08 153735 [Warning] Aborted connection 153735 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got timeout reading communication packets)
2021-02-19 11:47:10 154001 [Warning] Aborted connection 154001 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:10 154000 [Warning] Aborted connection 154000 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:10 153741 [Warning] Aborted connection 153741 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got timeout reading communication packets)
2021-02-19 11:47:12 154007 [Warning] Aborted connection 154007 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:12 154006 [Warning] Aborted connection 154006 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:12 154005 [Warning] Aborted connection 154005 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:12 154004 [Warning] Aborted connection 154004 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:12 154003 [Warning] Aborted connection 154003 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:13 153747 [Warning] Aborted connection 153747 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got timeout reading communication packets)
2021-02-19 11:47:14 154012 [Warning] Aborted connection 154012 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:14 154011 [Warning] Aborted connection 154011 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:15 153753 [Warning] Aborted connection 153753 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got timeout reading communication packets)
InnoDB: ###### Diagnostic info printed to the standard error stream
2021-02-19 11:47:16 0 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
210219 11:47:16 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 10.4.17-MariaDB-log
key_buffer_size=33554432
read_buffer_size=16777216
max_used_connections=142
max_threads=1002
thread_count=109
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 24682647 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x40000
/data/mariadb/bin/mysqld(my_print_stacktrace+0x2e)[0x5635b663de1e]
/data/mariadb/bin/mysqld(handle_fatal_signal+0x30f)[0x5635b604b3af]
/lib64/libpthread.so.0(+0x330de0f7e0)[0x7f0e427e47e0]
/lib64/libc.so.6(gsignal+0x35)[0x7f0e416a54f5]
/lib64/libc.so.6(abort+0x175)[0x7f0e416a6cd5]
2021-02-19 11:47:17 154018 [Warning] Aborted connection 154018 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:17 154017 [Warning] Aborted connection 154017 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:47:17 154016 [Warning] Aborted connection 154016 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
/data/mariadb/bin/mysqld(+0xc382f0)[0x5635b63412f0]
/data/mariadb/bin/mysqld(+0xbf07c2)[0x5635b62f97c2]
/lib64/libpthread.so.0(+0x330de07aa1)[0x7f0e427dcaa1]
2021-02-19 11:47:18 153758 [Warning] Aborted connection 153758 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got timeout reading communication packets)
/lib64/libc.so.6(clone+0x6d)[0x7f0e4175bc4d]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /data/mariadb_data
Fatal signal 11 while backtracing
2021-02-19 11:47:27 0 [Note] InnoDB: Using Linux native AIO
2021-02-19 11:47:27 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-02-19 11:47:27 0 [Note] InnoDB: Uses event mutexes
2021-02-19 11:47:27 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-02-19 11:47:27 0 [Note] InnoDB: Number of pools: 1
2021-02-19 11:47:27 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-02-19 11:47:27 0 [Note] InnoDB: Initializing buffer pool, total size = 96G, instances = 8, chunk size = 128M
2021-02-19 11:47:31 0 [Note] InnoDB: Completed initialization of buffer pool
2021-02-19 11:47:32 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-02-19 11:47:33 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=12397809980512
2021-02-19 11:47:42 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 861 row operations to undo
2021-02-19 11:47:42 0 [Note] InnoDB: Trx id counter is 119829882
2021-02-19 11:47:42 0 [Note] InnoDB: Starting final batch to recover 170415 pages from redo log.
2021-02-19 11:47:47 0 [Note] InnoDB: To recover: 168236 pages from log
2021-02-19 11:48:02 0 [Note] InnoDB: To recover: 154841 pages from log
2021-02-19 11:48:17 0 [Note] InnoDB: To recover: 146890 pages from log
2021-02-19 11:48:32 0 [Note] InnoDB: To recover: 139733 pages from log
2021-02-19 11:48:47 0 [Note] InnoDB: To recover: 132848 pages from log
2021-02-19 11:49:02 0 [Note] InnoDB: To recover: 125675 pages from log
2021-02-19 11:49:17 0 [Note] InnoDB: To recover: 118673 pages from log
2021-02-19 11:49:32 0 [Note] InnoDB: To recover: 111753 pages from log
2021-02-19 11:49:47 0 [Note] InnoDB: To recover: 104255 pages from log
2021-02-19 11:50:02 0 [Note] InnoDB: To recover: 97230 pages from log
2021-02-19 11:50:17 0 [Note] InnoDB: To recover: 89903 pages from log
2021-02-19 11:50:32 0 [Note] InnoDB: To recover: 82002 pages from log
2021-02-19 11:50:47 0 [Note] InnoDB: To recover: 74631 pages from log
2021-02-19 11:51:02 0 [Note] InnoDB: To recover: 68116 pages from log
2021-02-19 11:51:17 0 [Note] InnoDB: To recover: 61849 pages from log
2021-02-19 11:51:32 0 [Note] InnoDB: To recover: 54565 pages from log
2021-02-19 11:51:47 0 [Note] InnoDB: To recover: 43859 pages from log
2021-02-19 11:52:02 0 [Note] InnoDB: To recover: 37005 pages from log
2021-02-19 11:52:17 0 [Note] InnoDB: To recover: 30065 pages from log
2021-02-19 11:52:32 0 [Note] InnoDB: To recover: 23362 pages from log
2021-02-19 11:52:47 0 [Note] InnoDB: To recover: 16618 pages from log
2021-02-19 11:53:02 0 [Note] InnoDB: To recover: 9739 pages from log
2021-02-19 11:53:17 0 [Note] InnoDB: To recover: 1741 pages from log
2021-02-19 11:53:22 0 [Note] InnoDB: Last binlog file './mysql-bin.000001', position 7587824
2021-02-19 11:53:22 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2021-02-19 11:53:22 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2021-02-19 11:53:22 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2021-02-19 11:53:22 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-02-19 11:53:22 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-02-19 11:53:22 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2021-02-19 11:53:22 0 [Note] InnoDB: Waiting for purge to start
2021-02-19 11:53:22 0 [Note] InnoDB: 10.4.17 started; log sequence number 12397810010280; transaction id 119829883
2021-02-19 11:53:22 0 [Note] InnoDB: Loading buffer pool(s) from /data/mariadb_data/ib_buffer_pool
2021-02-19 11:53:22 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-02-19 11:53:22 0 [Warning] Plugin 'FEDERATED' is of maturity level gamma while the server is stable
2021-02-19 11:53:22 0 [Note] Server socket created on IP: '::'.
2021-02-19 11:53:22 0 [Warning] 'user' entry 'root@privacy-db' ignored in --skip-name-resolve mode.
2021-02-19 11:53:22 0 [Warning] 'proxies_priv' entry '@% root@privacy-db' ignored in --skip-name-resolve mode.
2021-02-19 11:53:22 0 [Note] Reading of all Master_info entries succeeded
2021-02-19 11:53:22 0 [Note] Added new Master_info '' to hash table
2021-02-19 11:53:22 0 [Note] /data/mariadb/bin/mysqld: ready for connections.
Version: '10.4.17-MariaDB-log'  socket: '/tmp/mysql.sock'  port: 3306  MariaDB Server
2021-02-19 11:53:26 0 [Note] InnoDB: Rolled back recovered transaction 119825411
2021-02-19 11:53:26 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2021-02-19 11:53:30 34 [Warning] Aborted connection 34 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:30 33 [Warning] Aborted connection 33 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:30 32 [Warning] Aborted connection 32 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:30 31 [Warning] Aborted connection 31 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:30 30 [Warning] Aborted connection 30 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:30 28 [Warning] Aborted connection 28 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:32 35 [Warning] Aborted connection 35 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:32 36 [Warning] Aborted connection 36 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:32 49 [Warning] Aborted connection 49 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:32 38 [Warning] Aborted connection 38 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)
2021-02-19 11:53:32 37 [Warning] Aborted connection 37 to db: 'xxxDB' user: 'xxxuser' host: '192.168.10.77' (Got an error reading communication packets)'

발생로그를 확인해보니 특정 테이블에 insert를 할 때마다 DB가 요동치다가 결국 죽는 것으로 확인했다.
이 테이블은 파티션테이블로 전체데이터는 약 30억건 정도 있는 테이블인데..
인덱스는 깨진 것을 확인했다.

--> DB 업그레이드하다 인덱스가 깨진 것 같다. MyISAM에서는 흔한 증상인데 innoDB에서 발생하니 좀 의외이긴하다.

일단 기도하는 마음으로 count(*)를 날려본다. 조회가 안된다면 PK가 깨진것이다. --> 조회가 안되면... 아.. 오늘이 퇴사하는 날이네? 라고 생각하면 된다

(innodb엔진 테이블의 모든데이터는 pk를 기준으로 데이터를 쌓고 모든 데이터에 pk의 시퀀스가 있어 복구하기 쉽지 않다)

MariaDB [xxxDB]> select count(*) from TB_xxx partition (p202102);
+-----------+
| count(*)  |
+-----------+
| 295327224 |
+-----------+
1 row in set (11 min 40.089 sec)

다행 PK는 깨지지 않았다 ㅠ
그럼 second index 가 깨진 것이고 이것을 복구하는 방법은 
1) shutdown이 가능하다면 innodb 복구 1~6 중에 해서 복구가가능하고, 
2) shutdown이 불가능하면 테이블스키마를 새로파고 insert into~로 데이터만 가져다 복구하는 방법
3) .ibd 파일만가지고가서 tablespace 교체로 복구하는 방법이 있다.

데이터가 거의 3억건이라서 원래는 3)번을 해야하는데 파티션 테이블이고 생각보다 복잡해질 거 같아 2)으로 진행했다.
테이블 스키마를 새로생성하고 insert 를 진행하는데
그런데?... insert 가 되지 않았다;
어떤 문제인지 테이블에 데이터를 하나하나씩 검토중에 datetime 형식의 파일이 이상하게 들어가 있는 것을 확인했다;

5033-11-13 23:34:31 8675-08-18 08:29:33

데이터가 깨졌다. 
DB 버전업하고 데이터가 꺠진것이다.ㅠ 하지만 다행이다. 이미 통계쪽 백업은 배치로 만들어놓아서 당장 전전월의 raw 데이터가 필요하진 않다.
한달치만 살리면 된다.

일단 테이블을 교체해서 새로 들어오는 데이터는 정상적으로 쌓이는 거을 확인했다. 복구는 개발쪽과 협의해서 raw 파일은 있으니 월말 전까지만 다시 insert 하면 된다.

추가로 확인해보니 DB 10.4.17로 업그레이드후.. 나머지 테이블은 1000만건, 3000만건 등등.. 멀쩡한데, 

30억건 6억건 되는 테이블 2개만 datatime 컬럼 데이터가 깨졌다.ㅠ
이 정도 큰 대용량 테이블은 제대로 업그레이드 지원이 되지 않은 거 같다.

아.. 새벽 5시네 이제 별일 없기를..
1차 대응 끝.

SQL 튜닝하려고 개발 DB를 multi instance로 구축해놓고 필요할 때

migration 해서 사용하는데 mirgration 에러가 나서 확인해보니 디스크용량이 부족하다고 한다..
근데 디스크 빵빵한 걸로 알고 있는데???

일단 파티션별로 디스크 용량을 확인해본다

# df -Th
Filesystem           Type   Size  Used Avail Use% Mounted on
/dev/sda2            ext4    20G  4.0G   15G  22% /
tmpfs                tmpfs   16G     0   16G   0% /dev/shm
/dev/sda1            ext4   477M  142M  310M  32% /boot
/dev/sda5            ext4    20G  9.7G  9.0G  52% /usr
/dev/sda7            ext4   3.9G  927M  2.8G  26% /var
/dev/sda6            ext4   3.9G  8.0M  3.7G   1% /tmp
/dev/sdb1            ext4   1.1T  938G  107G  90% /data
/dev/sda8            ext4   212G  136G   66G  68% /backup
xxx.xxx.xxx.xxx:/backup2 nfs    2.5T  1.9T  515G  79% /backup2


# du -h --max-depth=1
11M	./xxDB
1.1G	./xxDB
6.5G	./xxxTDB
22M	./mysql
31G	./zzDB
1.1M	./performance_schema
156K	./test
17G	./zzz
8.0K	./backup
617M	./vvv
676K	./sys
35G	./xxDB
829G	. 

//뭐야 이거; 현재경로에 829G 파일이 있다고??

어떤 파일인지 좀 더 확인해본다.

# ls -lh
합계 738G
drwxr-x--- 2 mysql mysql  12K 2020-10-13 13:43 xxDB
drwxr-x--- 2 mysql mysql  20K 2020-02-28 17:35 xxxDB
drwxr-x--- 2 mysql mysql  52K 2021-02-22 18:49 xxxx
drwxr-x--- 2 mysql mysql  20K 2021-02-16 14:08 xxx
drwxr-x--- 2 mysql mysql  12K 2021-02-16 15:05 zzDB
drwxr-x--- 2 mysql mysql 4.0K 2021-02-02 18:56 ttDB
drwxr-x--- 2 mysql mysql  40K 2021-02-23 10:07 xxxxDB
-rw-r----- 1 mysql mysql   56 2020-02-28 17:45 auto.cnf
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:34 backup
-rw-r----- 1 mysql mysql  36K 2021-02-10 15:22 ddl_log.log
-rw-r----- 1 mysql mysql 558K 2020-11-23 11:23 ib_buffer_pool
-rw-r----- 1 mysql mysql 256M 2021-02-23 10:10 ib_logfile0
-rw-r----- 1 mysql mysql 256M 2021-02-23 10:10 ib_logfile1
-rw-r----- 1 mysql mysql 256M 2021-02-23 10:07 ib_logfile2
-rw-r----- 1 mysql mysql 500M 2021-02-23 10:10 ibdata1
-rw-r----- 1 mysql mysql 500M 2021-02-23 10:10 ibdata2
-rw-r----- 1 mysql mysql 500M 2021-02-23 10:08 ibdata3
-rw-r----- 1 mysql mysql 5.9G 2021-02-23 10:10 ibdata4
-rw-r----- 1 mysql mysql 730G 2021-02-23 10:06 ibtmp1
-rw-r----- 1 mysql mysql 2.8K 2020-02-28 17:43 mvno-my.cnf
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:35 mysql
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:34 performance_schema
-rw-r----- 1 mysql mysql    6 2020-11-23 11:23 privacy-db.pid
drwxr-x--- 2 mysql mysql  12K 2020-02-28 17:43 sys
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:43 test
-rw-r----- 1 mysql mysql   22 2020-02-28 17:43 xtrabackup_binlog_pos_innodb
-rw-r----- 1 mysql mysql  578 2020-02-28 17:43 xtrabackup_info

-rw-r----- 1 mysql mysql 730G 2021-02-23 10:06 ibtmp1
//헐 이게 뭐냐?? ibtmp1에 대해 알아봐야겠다.

* ibtmp1 이란?

[MySQL Internals] Temporary Tablespace
압축되지 않고 사용자가 생성한 임시 테이블과 디스크에 생성되는 내부적인 임시 테이블들이 shared temporary tablespace 에 생성됩니다.
innodb_temp_data_file_path 옵션으로 상대 경로, 이름, 사이즈, 데이터파일의 속성을 설정할 수 있습니다.
아무것도 설정하지 않으면 기본적으로 innodb_data_home_dir 경로에 ibtmp1:12M:authextend 속성으로 생성됩니다.

[Note]
MySQL 5.6에서는 압축되지 않은 테이블에 대한 임시 테이블 스페이스는 개별 file-per-table 테이블 스페이스에 생성되었었습니다.
또는 innodb_file_per_table 설정이 안되어 있다면 시스템 테이블 스페이스에 생성됩니다.
5.7의 Temporary Tablespace 는 기존 개별 file-per-table 테이블 스페이스를 생성하고 삭제할 필요가 없기 때문에 성능 이점을 가집니다.
또한 전용 Temporary Tablespace가 있기 때문에 temp table 에 대한 metadata 를 시스템 테이블에 생성할 필요가 없어집니다.

[Mysql 5.7에서 임시테이블에 대한 성능개선]

Mysql ver 5.7.2에서 일반 임시 테이블과 압축 임시테이블 그리고 거기에 연관된 오브젝트들을 위한 새로운 타입의 Undo Log가 소개되었다. 임시 테이블의 내용은 Crash Recovery에서 사용되지 않기 때문에 redo log가 필요하지 않다. 즉, 임시테이블의 정보는 서버가 운영 중일때, 롤백해야 하는 상황에서만 필요하다. 리두로그를 만들지 않는 Undo Log는 해당 임시테이블과 거기에 관련된 오브젝트를 위한 redo logging으로 인해 발생하는 Disk I/O 를 피할수 있기 때문에 성능에 도움을 준다. 임시테이블에 대한 Undo log는 임시테이블 스페이스에 위치한다. 기본으로 생성되는 임시테이블 스페이스 파일은 ibtmp1이라는 이름을 가진다. 이것은 따로 지정하지 않으면 Data Directory에 위치하게 되고, 이것은 Mysql이 Startup 될 때 자동으로 재성생된다. 사용자의 요구에 따라 위치를 변경할 수 있는데 이때 사용하는 시스템 변수는 innodb_temp_data_file_path이다.

--> 아~ 임시파일을 저장하는 파일이군..

redo log를 쓰지않으니 Disk I/O 이슈는 없었던 것이고, DB를 재시작하게 되면 삭제하고 다시 생성하는 것으로 확인했다.

mysql> SELECT @@innodb_temp_data_file_path;
+------------------------------+
| @@innodb_temp_data_file_path |
+------------------------------+
| ibtmp1:12M:autoextend        |
+------------------------------+
1 row in set (0.00 sec)

#사용량 확인
mysql> SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G;
*************************** 1. row ***************************
             FILE_ID: 3293
           FILE_NAME: ./ibtmp1
           FILE_TYPE: TEMPORARY
     TABLESPACE_NAME: innodb_temporary
       TABLE_CATALOG: 
        TABLE_SCHEMA: NULL
          TABLE_NAME: NULL
  LOGFILE_GROUP_NAME: NULL
LOGFILE_GROUP_NUMBER: NULL
              ENGINE: InnoDB
       FULLTEXT_KEYS: NULL
        DELETED_ROWS: NULL
        UPDATE_COUNT: NULL
        FREE_EXTENTS: 736959
       TOTAL_EXTENTS: 747404
         EXTENT_SIZE: 1048576
        INITIAL_SIZE: 12582912
        MAXIMUM_SIZE: NULL
     AUTOEXTEND_SIZE: 67108864
       CREATION_TIME: NULL
    LAST_UPDATE_TIME: NULL
    LAST_ACCESS_TIME: NULL
        RECOVER_TIME: NULL
 TRANSACTION_COUNTER: NULL
             VERSION: NULL
          ROW_FORMAT: NULL
          TABLE_ROWS: NULL
      AVG_ROW_LENGTH: NULL
         DATA_LENGTH: NULL
     MAX_DATA_LENGTH: NULL
        INDEX_LENGTH: NULL
           DATA_FREE: 772806803456
         CREATE_TIME: NULL
         UPDATE_TIME: NULL
          CHECK_TIME: NULL
            CHECKSUM: NULL
              STATUS: NORMAL
               EXTRA: NULL
1 row in set (0.05 sec)

* 그렇다면 너무 커진 Temporary Tablespace 를 줄이기 위한 방법은 ?

--> DB를 재시작하여 기본설정으로 Tablespace 를 재생성하도록 하는 방법밖에 없다고 한다

하지만 다행이다; 이건 개발 DB다.

따라서 설정 시에 디스크 사이즈를 고려하여 너무 크게 설정하지 않도록 max 를 제한할 수 있는 방법도 있다

[mysqld]
innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:500M

주의할 점은..

쿼리가 수행 도중에 MAX 에 도달하게 되면 table is full 에러를 내면서 쿼리는 실패됩니다. --> 잠깐만요..; 뭐라고요?
하지만 무제한으로 tablespace 를 제공할 수는 없기 때문에 적절한 사이즈를 정해야 합니다.

--> DB는 분기별로 정기 PM이 있어서 굳이 넣을 필요가 있을까 싶다.. 그냥 재시작한다.

* DB shutdown 후 파일확인

# ls -lh
합계 8.1G
drwxr-x--- 2 mysql mysql  12K 2020-10-13 13:43 xxDB
drwxr-x--- 2 mysql mysql  20K 2020-02-28 17:35 xxxDB
drwxr-x--- 2 mysql mysql  52K 2021-02-22 18:49 zzz
drwxr-x--- 2 mysql mysql  20K 2021-02-23 18:35 xxDB
drwxr-x--- 2 mysql mysql  12K 2021-02-16 15:05 xxDB
drwxr-x--- 2 mysql mysql 4.0K 2021-02-02 18:56 xxDB
drwxr-x--- 2 mysql mysql  52K 2021-02-23 12:53 xxxxDB
-rw-r----- 1 mysql mysql   56 2020-02-28 17:45 auto.cnf
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:34 backup
-rw-r----- 1 mysql mysql  36K 2021-02-10 15:22 ddl_log.log
-rw-r----- 1 mysql mysql 2.7M 2021-02-24 08:21 ib_buffer_pool
-rw-r----- 1 mysql mysql 256M 2021-02-24 08:21 ib_logfile0
-rw-r----- 1 mysql mysql 256M 2021-02-24 03:05 ib_logfile1
-rw-r----- 1 mysql mysql 256M 2021-02-24 08:21 ib_logfile2
-rw-r----- 1 mysql mysql 500M 2021-02-24 08:21 ibdata1
-rw-r----- 1 mysql mysql 500M 2021-02-24 08:21 ibdata2
-rw-r----- 1 mysql mysql 500M 2021-02-24 03:13 ibdata3
-rw-r----- 1 mysql mysql 5.9G 2021-02-24 08:21 ibdata4
-rw-r----- 1 mysql mysql 2.8K 2020-02-28 17:43 mvno-my.cnf
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:35 mysql
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:34 performance_schema
drwxr-x--- 2 mysql mysql  12K 2020-02-28 17:43 sys
drwxr-x--- 2 mysql mysql 4.0K 2020-02-28 17:43 test
-rw-r----- 1 mysql mysql   22 2020-02-28 17:43 xtrabackup_binlog_pos_innodb
-rw-r----- 1 mysql mysql  578 2020-02-28 17:43 xtrabackup_info

//DB shutdown 후 확인해보니 파일이 사라졌다. DB를 내릴때 같이 삭제하는 로직인 것을 알수 있다.

DB를 다시 startup 하고 ls -lh로 파일을 확인해보니 ibtmp1 파일이 12M 로 생성된 것을 확인할 수 있었다.

파티션별 디스크 용량한번 다시 확인

df -Th
Filesystem           Type   Size  Used Avail Use% Mounted on
/dev/sda2            ext4    20G  4.0G   15G  22% /
tmpfs                tmpfs   16G     0   16G   0% /dev/shm
/dev/sda1            ext4   477M  142M  310M  32% /boot
/dev/sda5            ext4    20G  9.7G  9.0G  52% /usr
/dev/sda7            ext4   3.9G  927M  2.8G  26% /var
/dev/sda6            ext4   3.9G  8.0M  3.7G   1% /tmp
/dev/sdb1            ext4   1.1T  224G  821G  22% /data
/dev/sda8            ext4   212G  136G   66G  68% /backup
xxx.xxx.xxx.xxx:/backup2 nfs    2.5T  1.9T  497G  80% /backup2

이슈 해결 끝~

참조:
https://m.blog.naver.com/PostView.nhn?blogId=sory1008&logNo=221381987533&proxyReferer=http:%2F%2Fwww.google.co.kr%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3D%26esrc%3Ds%26source%3Dweb%26cd%3D%26ved%3D2ahUKEwjL3e3s6f7uAhUKPnAKHcIqCL8QFjAAegQIAhAD%26url%3Dhttp%253A%252F%252Fm.blog.naver.com%252Fsory1008%252F221381987533%26usg%3DAOvVaw3NPXn05xI9F2uUudbJ4-Vf
https://mysqldba.tistory.com/284

연말부터 약간 딴짓하고 있다. 기사실기등.. 결국 실패하긴했지만 CS공부가 많이 됐다.

다시 새해가 시작되었으니 대용량처리관련 nosql공부를 해볼까

법인카드로 사려다가 이성욱님 책은 개인적으로 소장하고 싶어서 개인카드로 샀다.

내돈들여서 산거니까 더 열심히 읽어봐야지..

근데 800page가 넘는다; ㅎㄷㄷ

Real MysqlDB 그렇지만 이것도 초심자가 읽기엔 참 빡세다.

이것도 몇회독은 해야 정신차리고 알아듣겠네..ㅎㅎ

# Adding multiple columns AFTER a specific column in MySQL (mysql 5.7.19)

after 를 사용하게되면 algorithm = copy로 처리하게되서 테이블의 용량에 따라 컬럼 추가시에는 성능이슈가 발생할 수도 있다.

예를 들어 테이블 TMP_LOAD_20201203에 x0 컬럼 뒤에 컬럼 5개를 추가한다고하면

#잘못된 예)
ALTER TABLE TESTDB.TMP_LOAD_20201203 ADD COLUMN x1 VARCHAR(8) DEFAULT NULL AFTER x0; 
ALTER TABLE TESTDB.TMP_LOAD_20201203 ADD COLUMN x2 VARCHAR(1) DEFAULT NULL AFTER x1; 
ALTER TABLE TESTDB.TMP_LOAD_20201203 ADD COLUMN x3 VARCHAR(1) DEFAULT NULL AFTER x2; 
ALTER TABLE TESTDB.TMP_LOAD_20201203 ADD COLUMN x4 VARCHAR(1) DEFAULT NULL AFTER x3; 
ALTER TABLE TESTDB.TMP_LOAD_20201203 ADD COLUMN x5 VARCHAR(1) DEFAULT NULL AFTER x4; 
// 컬럼 하나 추가할때마다 임시테이블을 만드는 작업을 하고 있어 느리다.

#수정 예)
ALTER TABLE TESTDB.TMP_LOAD_20201203 
ADD COLUMN x1 VARCHAR(8) DEFAULT NULL AFTER x0, 
ADD COLUMN x2 VARCHAR(1) DEFAULT NULL AFTER x1, 
ADD COLUMN x3 VARCHAR(1) DEFAULT NULL AFTER x2, 
ADD COLUMN x4 VARCHAR(1) DEFAULT NULL AFTER x3, 
ADD COLUMN x5 VARCHAR(1) DEFAULT NULL AFTER x4; 
// 임시테이블 한번만 만들고 나머지는 컬럼모두 추가~ 아래꺼가 훨씬 빠르다.

after column 을 쓰게되면 algorithm = inplace 를 사용할 수 없다. mysql 8에서도 맨뒤에 컬럼을 추가하는 경우를

제외하고는 instant를 쓸 수 없는 것으로 알고 있다.

컬럼 순서 재정렬 이슈.. 이번에 정리해두자.

끝~

참조 : stackoverflow.com/questions/17541312/adding-multiple-columns-after-a-specific-column-in-mysql