따봉 구걸남's 블로그

xtrabackup 으로 풀백업을 받고 copy/move back 으로 복구를 하려면 
기존 데이터파일들을 삭제 해야 한다.
혹시나 필요할 경우를 대비해서 삭제하지 않고 mv 로 보관해 둘수도 있는데
그런 경우 나중에 데이터파일 하나를 가져와서 복구를 할수도 있다. 

데이터파일을 cp 로 가져와서 복구하는 테스트를 해보자. 

1. 테스트 시나리오

0) xtrabackup prepare 까지 완료
1) xtrabackup copy back 전 mv 로 백업 
2) copy-back 
3) 빈테이블 생성 후 discard 

=> create table imp_test;
alter table imp_test discard tablespace;

4) mv 로 복구 & import tablespace

=> alter table imp_test import tablespace;

그냥 데이터파일을 가져올경우 DB 에서 인식을 못해서 discard & import 과정을 거쳐줘야 한다. 
import 명령을 실행하면 아래 과정이 일어난다. 

2. import 명령시 내부 프로세스

1) 메타데이터 잠금 (Metadata Lock, MDL)
테이블의 구조(정의)를 확정 짓고, 다른 세션이 해당 테이블을 수정하거나 읽지 못하게 잠금

2) 파일 유효성 검사 및 정합성 체크
.ibd 파일을 데이터 디렉터리로 복사한 후 IMPORT를 지시하면, InnoDB 엔진은 아래 작업을 수행 

Schema Mismatch 체크: .cfg 파일(메타데이터)을 읽어 현재 생성된 테이블 정의와 실제 .ibd 파일 내의 정보 대조

Tablespace ID 갱신: 복구파일의 내부 Tablespace ID를 현재 서버의 데이터 딕셔너리에 등록된 ID와 일치하게 파일 헤더 수정
Dirty Pages 플러시: 가져오려는 테이블 공간과 관련된 기존 캐시 데이터를 정리

3) 페이지 레벨의 LSN(Log Sequence Number) 조정
가장 시간이 많이 걸리고 부하가 큰 작업
가져온 .ibd 파일 내의 모든 데이터 페이지에는 이전 서버에서 쓰던 LSN 정보가 담겨 있다. 
MySQL은 이 페이지들을 하나하나 읽으며 현재 서버의 시스템 LSN에 맞게 재작성하는 과정을 거침

메타데이터만 변경하는 과정이 아니고 모든 트랜잭션이 멈추고, (작업대상 테이블의) 모든 page 를 검사한다. 
전체 디비를 사용할수 없으니 작업전 신중해야 한다. 

세금납부는 보통 pc 로 하지만, 가끔 여의치 않은 환경과 시간의 제약으로 모바일로 해야할때가 있는데..
그때마다 매번 헷갈려서 정리해본다. 


모바일 손택스로 부가세 신고 가능하다. '손택스' 라는 이름은 매번 잘 지은것 같다는 생각 듦.
여튼 부가세는 손택스로 신고하지만 납부를 하려면 '지로앱' 으로 넘어가게 되는데..
'지로앱' 에 저장된 공동인증서가 없으면 결국 사용못함.
그렇지만 모바일에 공동인증서는 있어서 주식매매나 금융거래에 이미 쓰고 있지만 안드로이드에서는 
앱간에 공유가 안되서 사용하는 앱마다 pc에서 앱으로 옮겨서 등록해야 한다. 
(이걸 몰라서 왜 공동인증서를 못찾나 한참 고민함)

근데.. pc 를 사용할수 없어서 모바일을 사용하는 건데, pc 에서 복사를 해야한다니..
그때는 또 다른 인증 방법인 금융인증서 라는게 있다. 


# 금융인증서 공동인증서 차이

범용성이 부족한것 말고는 공동인증서를 대체하기에 충분해 보인다. 
 


# 손택스 부가세 납부 순서

1. 홈택스 부가세 신고 - 매입세액 및 기타공제 작성 
  => 이건 pc에서 미리 해두자
2. 손택스 부가세 납부 - 개인으로 로긴
3. 금융인증서 로긴 - 지로 앱 연결 - 납부하기 - 금융인증서 로긴 - 끗

날씨가 갑자기 추워졌다.
추울땐 무조건 롱패딩이지.. 그러나 롱패딩의 치명적 단점이 있으니..
바로 활동성에 제약이 있다는것.
아무래도 허벅지까지 커버되는 롱패딩을 입고 뛰거나, 자전거 타는것은 불편하다.

어쩔수 없이 숏패딩을 입자니 추위에 노출된 나의 하체..
바로 이럴때 필요한 것이 다이소 내복.. (이라 쓰고 없어보이니까 에어로 웜 이라 읽는다.)

효성이 만들었다고 써있는데, 기능성 폴리에스터 소재를 생산하는 효성티앤씨의 소재를 사용한 듯 하다.
가격은 5천원으로 다이소 최고 럭셔리상품 중 하나이다. 

경쟁상대를 생각하자면  내복, 타이즈 또는 유니클로 히트텍 등이 경쟁 상대 일 텐데 오천원이라는 가격은 가성비 절대 원탑이다.
마침 탑텐도 내복 가격 확인해봤는데 세일해서 12900 이다.
유니클로는 더 비싼 16900 이고..

# 후기

다만 나는 급하게 너무 추워서 껴입을 것을 사러 간것인데 그날 내가 간 다이소 매장은 사이즈가 95 하나만 남았다.
그래도 어차피 안에 껴 입고 늘어나는 소재니까 한참 고민후에 구매했다. (본인 키 185, 체중 80 )
나한테 작은 95 사이즈라서 혹시나 엉덩이가 낑길까 했는데 소재가 신축성있고 얇아서 그런지 그런 느낌은 없었다.
확실히 입고 안 입고는 보온에 차이가 있지만 하의 단독으로 입기에는 얇아서 영하 10도 에서는 무리라고 본다.

예전에도 가볍게 입고 야외 러닝나갔다가 바람이 너무 거세서 5000원 털쪼끼를 사서 야무지게 입은 적이 있는데,
그럴때마다 다이소 방한용품은 한줄기 빛, god 이다. 추울때 돌아다니다 감기걸리면 약값만 오천원 이상이다.

 
KT스카이라이프 인터넷을 3년넘게 사용중인데,
사용 후기 및 인터넷 속도 버벅일때 체크 할것 정리해봤다.

인터넷을 200MB 쓰다가 요즘 유튜브 버벅임이 점점 심해져서 500MB 으로 변경하면 좀 나아질까 싶어서 변경 해보았다.
변경 후 처음 며칠은 괜찮은가 싶더니 다시 예전처럼 버벅이게 되었다. 

평일 저녁에는 대체로 괜찮지만 주말 저녁에는 버벅임이 유독 심해지는데 동영상을 배속으로 보는 입장에서 
정속으로 보는 것보다 못한 느낌이 들어 매우 답답한 기분과 함께 요금 업그레이드했지만 품질차이를 못느껴서 사기당한 기분.

기사님 AS 요청하고, 다음날 왔다 갔지만 자기가 측정할땐 500MB 이 잘 나온다며 문제없다 말하고 가심.
나는 불편을 겪고있는데, 서비스 제공자는 문제가 없다고 하니 답답하지만 혼자 고민해보았다. 
문제가 뭘까 생각해보니 
 

1. 속도 측정
  느낌적인 느낌말고 진짜 속도가 얼마나 나오는지 내가 측정해보자.
  보통 fast.com 으로 속도 측정을 했었는데,  진흥원 nia 가 국내사이트 이기도 하고 다양하게 데이터를 제공해준다. 
더 좋은게 있으니 안 쓸 이유가 없다.

https://speed.nia.or.kr/index.asp 

 
업/다운로드 속도, 지연시간, 손실률 정보 도 제공해준다. 

 
실제로 측정해보고 내가 가입한 상품보다 떨어지는 속도가 나온다면, 여기 데이터를 근거로 해지를 요청하면 
위약금 없이 해지 가능하다고 주워들었다. (안될수도 있다)

 
실제 내가 가입한 상품은 500mb 이지만 와이파이임을 감안하면 300후반은 그럴수 있음



2. 병목 찾기 

 외부에서 측정했을때는 500MB 속도가 나오는데 실제 사용에 불편을 느낀다면 무엇을 체크해야할까..
 
1) 와이파이로 변경 후 측정 
   유선의 문제가 있을수 있다. 
   유선이 무선보다 속도가 떨어진다면 유선에 문제가 있는것이다. ( 나의 경우 그러했다.)

2) 유선의 병목 
 요즘 나오는 노트북은 랜선 꽂는 포트가 없는 경우가 많다. 이때 랜포트 젠더로 연결해서 사용할수 있는데 usb2.0 의 경우 100MB 이상의 속도를 지원하지 못하는 경우 발생한다. 

랜 케이블의 경우도 100MB 이상 지원 못하는 종류가 있는데 나의 경우엔 cat 6 로 해당 케이블은 10gbps 까지 사용가능. 
 간혹 커뮤니티에 100mb 에서 제한 걸린듯 더 안올라간다는 후기 있는데 비슷한 케이스 많을듯 
cable은 성능차이에 비해 가격차이가 크지않다. 몇천원만 더주면 cat6 구매 가능하다.
랜선 젠더는 파는곳도 많지않고 가격차이 좀 있다. 
 

 3) 특정콘텐츠 ( 라이브스트리밍 )

라이브스트리밍을 즐겨보는 경우는 속도 외에 네크워크 안정성 문제도 있다.
패킷이 순간적 손실이나 지연 가능성 문제로 버벅일수 있다. 

 
4) 라이브 아니어도 버벅이는 경우

속도 측정시에도 문제 없고, 별다른 병목도 없고, 라이브 스트리밍도 아닌 vod 시청에도 문제가 발생한다면 스카이라이프의 구조적 문제일수 있다.

스카이라이프는 동축망을 공유해서 쓰는데 혼잡시 느려지는 문제가 있다. (항간에는 혼잡시 패킷을 확인하고 서비스사업자에 따라 속도를 낮춘다는 말이 있는데, 가능성이 낮은 얘기고 의심되면 속도 측정을 해보면 된다. )

KT 는 집까지 FTTH 로 직접 연결해서 혼잡시간도 버벅임 없지만 스카이라이프는 그렇지 못하다.
아정당이나 그런곳에 문의를 하면 결국 kt로 바꾸라고 추천하는 경우있는데 이런 구조적 문제가 있기에 일리있는 추천이다.
 
결국 못참겠다 싶으면 스카이라이프는 거르는게 답이고, 속도 측정이 별 의미가 없다. 
사실 내가 느끼는 서비스의 질이 중요한데 속도 측정에 문제 없으니 괜찮다고 말하는 행태는 기만행위다. 

글을 제대로 읽었다면 어떤 서비스제공자를 선택해야할지는 잘 알았으리라 생각된다.

 

최근 고환율 상황이 지속되는데

그 원인으로 지목되는것이 몇 있다.

대표적으로

1. 서학개미의 증가
2. 기업들 대미투자

이 중 유독 정부측은 서학개미에 대해 불편한 시선으로 바라보고 있는듯 하다.

근데 그들이 왜 원화를 버리고 달러자산을 매입하는지 생각을 해볼 필요가 있다.

내부적으로만 보자면

1. 정부의 돈풀기로 원화가치 하락
2. 미국과 금리역전 지속
3. 개선되고 있지만 여전한 한국 상장기업의 낮은 주주환원과 거버넌스 문제

미국이 금리도 높고 성장도 높다. 지금 미국주식계좌를 열어서 미국 단기 rp 금리를 확인해보면 7일짜리가 3.55% 이다.

굳이 미국주식까지 언급하지않아도 원화를 가지고있을 이유가 별로 없다.

올해 상법개정과 배당분리과세 영향으로 국장에 대한 기대감이 많이 반영되었지만 과연 장기적으로 효과가 지속될수있을지 생각해봐야한다.
서학개미가 국장으로 돌아오지 않는 이유도 결국 다시 돌아갈까봐 믿지못하는 불신이 있기 때문이다.

배당분리과세안도 결국 한시적으로 적용하겠다는 건데 누가 그걸 믿고 본인의 자산의 큰 포션을 국장에 장기투자 할수있는가

부동산은 매수를 하면 100% 내 것이다. (은행 대출이없다면) 시간에 따라 가치는 변할수 있지만 지분율은 변하지 않는다. 이것은 변하지 않는다. 근데 국장은 나의 지분율이 점점 희석이 되는 경우가 많다. 상장사의 이익이 최대주주에 유리하게 빼돌려지는 일도 많다. 이런것을 예전엔 '모르고 투자한 너의탓'으로 조롱당한곤 했다.

최근에 쿠팡이 해킹과 관련된 떠들썩한 이슈로 주가가 많이 빠지고, 미국에서 투자자들에게 집단소송이 진행중이란 소식이 들리는데, 그들의 입장은 '너희들의 늦은공시, 잘못된 정보로 손해를 입었으니 보상을 하라'는 것이다.

투자자를 보호해야지 자본시장이 산다. 그 간단하고 단순한 가치를 지키지 않고 자꾸 단기적, 한시적 정책만 누더기로 남발하고, 나중에 취소하고 그런식의 대응은 점점 신뢰를 잃어버려서 나중에는 정책 효과도 점점 미미 해지게 된다.

mysql 백업으로 percona xtrabackup 을 많이 사용한다. 
설치와 사용법 알아보자. 

1. 특징
 - 물리적백업방식
   파일을 물리적으로 백업하는 cp 하는 방식과 유사하다. 
   논리적 백업이 아니기에 테이블단위, 조건절 백업 등이 불가하다.    
   mysqldump 는 논리적 백업이지만 lock 을 필요로 한다. 
 - 증분백업가능
 - 온라인백업가능
   

2. 절차

 - backup
 - prepare
 - copy back / move back

backup 명령으로 파일을 카피하고, 데이터 파일 복사 중 발생하는 변경 사항은 
prepare 명령으로 트랜잭션 로그로 추적·보정해 서비스 중단 없이 일관된 스냅샷을 만든다.

사실 prepare 가 이상없이 진행되었으면 복구는 거의 완료된것이다. copy/move back 은 단순히 파일을 

경로(datadir) 로 이동할 뿐이기 때문이다. 

원본을 지우지 않는것이 copy-back , 원본을 지정된 경로로 mv 하는 것이 move-back 이다.

데이터파일이 매우 큰 사이즈라면 동일 파티션에 백업본을 받아놓고 move-back 하는 것이 다운타임을 줄일수있다. 

 
3. 옵션들

user
password
parallel
compress
compress threads
target dir
datadir
no lock

* io 병목으로 compress 쓰면 cpu가 더 일해서 빠르다

4. 설치 및  활용

xtrabackup 으로 풀백업하고 새로운 경로에 복원하는 테스트를 해보자. 

# 설치 

sudo dnf install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
sudo percona-release setup pxb80  # MySQL 8.0용 XtraBackup 8.0 활성화

sudo dnf update
sudo dnf install percona-xtrabackup-80

sudo rpm --import https://repo.percona.com/yum/RPM-GPG-KEY-Percona

# 설치 확인
rpm -qa | grep xtrabackup
xtrabackup --version



CREATE USER 'backup'@'%' IDENTIFIED BY 'Backup123!';
GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT, PROCESS, SELECT ON *.* TO 'backup'@'%';
GRANT BACKUP_ADMIN ON *.* TO 'backup'@'%';
FLUSH PRIVILEGES;

use mytest;

create table xtra(a int);

insert into xtra values(1);
insert into xtra values(2);
insert into xtra values(3);

commit;

select *
  from mytest.xtra
;  

select @@datadir
-- /var/lib/mysql/

 

# 기본 백업 테스트 (MySQL 실행 중)

xtrabackup  \
  --backup \
  --user=backup \
  --password=Backup123! \
  --datadir=/var/lib/mysql/ \
  --target-dir=/home/mysql/xtra \
  --no-lock 


xtrabackup  \
  --prepare \
  --target-dir=/home/mysql/xtra \
  --use-memory=2G
  

sudo systemctl stop mysqld


xtrabackup  \
  --copy-back  \
  --target-dir=/home/mysql/xtra \
  --datadir=/restore/mysql
   

sudo mkdir -p /restore/mysql
sudo chown -R mysql:mysql /restore/mysql
sudo chmod -R 750 /restore/mysql
 
sudo systemctl start mysqld
  

datadir = /home/mysql/restore
socket = /home/mysql/restore/mysql.sock  
 

sudo journalctl -xeu mysqld.service

  

sudo systemctl daemon-reload
sudo systemctl restart mysqld

   

 tail -100 /var/log/mysqld.log


sudo touch /restore/mysql/binlog.index
sudo chown mysql:mysql /restore/mysql/binlog.index
sudo chmod 644 /restore/mysql/binlog.index
sudo systemctl restart mysqld




# 잘못된 예
log_bin = /var/lib/mysql/mysql-bin

# 올바른 예 (datadir 기준 상대경로)
log_bin = mysql-bin
# 또는
log_bin = /new/mysql/data/mysql-bin




sudo chown -R mysql:mysql /restore/mysql/
sudo find /restore/mysql/ -type d -exec chmod 750 {} \;
sudo find /restore/mysql/ -type f -exec chmod 640 {} \;

sudo find /restore/mysql/ -type d -exec chmod 777 {} \;
sudo find /restore/mysql/ -type f -exec chmod 666 {} \;

 


move back은 (copy-back 에 비해) (동일파티션의 경우) 메타정보만 바뀌어서 빠를수 있지만 실패시 백업본을 다시 재복사 해야함.
bin log도 미리 지워줘야 (datadir 과 다르게 지정할경우 놓칠수있다.)

mysql 8.0 설치 on virtual box oraclelinux 9

1. virtual box 에 oraclelinux9 설치하기 

vmware 가 유료로 바뀌면서 열심히 virtual box 를 쓰고 있다. 
인스톨러 버전이 필요하면 아래 링크에서 다운받자. 
https://www.virtualbox.org/wiki/Downloads

오라클리눅스는 아래 링크에서 다운받자. 이번 포스팅에서는 9.6 버전을 이용할 것이다. 
https://yum.oracle.com/oracle-linux-isos.html

가상머신을 새로 생성하고 오라클리눅스를 설치하는 것은 매우 쉽다. 이전 글을 참조하자. 
가상머신에서 인터넷이 가능하게 네트워크 작업을 해주는것에 신경쓰자. 
https://riorio.tistory.com/403

# 방화벽 설정 

vi /etc/selinux/config
SELINUX=enforcing => disabled
  
sudo systemctl status firewalld
sudo systemctl stop firewalld

 # sudoer 추가
 
visudo /etc/sudoers

mysql  ALL=(ALL)       ALL

2. mysql 설치 

# mysql 버전 차이 

- 8.0 : 현재 가장 많이 사용하는 버전이지만 25.4 월로 premier support 종료. extended support 는  

- 8.4 : LTS 로 신규 설치한다면 고려해야하는 버전. 

sudo yum update -y 

sudo rpm -ivh mysql80-community-release-el9-1.noarch.rpm

sudo dnf install mysql-community-server
sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

# mysql-community-client-8.0.44-1.el9.x86_64.rpm의 공개 키는 설치되어 있지 않습니다 

=> 
sudo dnf clean all
sudo rpm -e gpg-pubkey --allmatches $(rpm -qa gpg-pubkey | grep mysql)

sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
sudo yum update -y

- 설치버전 확인 

yum list installed | grep mysql
rpm -qa | grep mysql 

 - mysqld 시작 
sudo systemctl start mysqld
sudo systemctl enable mysqld

3. CLI 접속  

- 최초 비밀번호 확인하기

sudo grep 'temporary password' /var/log/mysqld.log

=> u8HQ<*zinfxk

mysql -uroot -pu8HQ<*zinfxk
 

- 비번 변경 및 유저 추가 

ALTER USER 'root'@'localhost' IDENTIFIED WITH 'caching_sha2_password' BY 'Root123!';

CREATE USER 'mydba'@'%' IDENTIFIED BY 'Mydba123!';

GRANT ALL PRIVILEGES ON *.* TO 'mydba'@'%' WITH GRANT OPTION;


create database mytest;

# virtual box 를 중지했다가 resume 했을때 시간동기화 하기 

date

systemctl status chronyd
systemctl start chronyd       # 필요 시 시작
systemctl enable chronyd      # 부팅 시 자동 시작 설정
 
chronyc makestep

date

mysql을 서버에서 cli 로 접속할때가 있는데
편집기에서 작성한 쿼리를 붙여넣다 보면 자동완성기능때문에 쿼리가 제대로 인식이 안되는 경우가 있다. 한줄씩 붙여넣거나 sql 파일로 작성해서 source 로 실행하면 이문제를 해결할수있다.

혹은 자동완성 기능을 끄면 그대로 복붙한 쿼리를 사용가능하다.

mysql -u root -p  --skip-auto-rehash


# mysql cli 접속후 디비 작업이 많을경우에
접속이 안되고 "reading table information..."
뜨는 경우에도 사용할수있다

 
pt-online-schema-change (이하 pt-osc) 를 사용하면 대량건의 변경작업을 lock 을 적게 사용하면서 완료할수있다. 

pt-osc  동작 방식
1. 변경할 스키마가 적용된 새로운 임시 테이블(보통 _new 접두사 포함)을 생성 
2. 원본 테이블에 대한 트리거를 걸어 원본 데이터를 chunk 단위로 복사, 실시간 변경사항까지 신규 테이블에 반영
3. 데이터 복사가 완료되면 원본 테이블과 새로운 임시 테이블의 이름을 바꾸는 RENAME 수행.
4. 자동으로 임시 테이블을 DROP하여 정리. 온라인 상태에서 스키마 변경을 완료

즉, 아주짧은 시간의 lock (rename 시점) 으로, 온라인 변경 작업을 가능하게 설계된 도구이다. 

percona toolkit 설치 
sudo yum install -y perl perl-DBI perl-DBD-MySQL perl-Time-HiRes perl-TermReadKey
wget https://downloads.percona.com/downloads/percona-toolkit/3.6.0/binary/tarball/percona-toolkit-3.6.0_x86_64.tar.gz 
tar xvf percona-toolkit-3.6.0_x86_64.tar.gz 
cd percona-toolkit-3.6.0/bin 
./pt-online-schema-change --version
 
테스트 시나리오
대량건을 가진 big table 의 collate 변경 작업  utf8mb4_general_ci ->  utf8mb4_unicode_ci

CREATE TABLE big_table (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    description VARCHAR(255) COLLATE utf8mb4_general_ci NOT NULL,
    PRIMARY KEY (id)
) ENGINE=InnoDB;

INSERT INTO big_table (description)
SELECT CONCAT('sample text ', seq) 
FROM (SELECT @rownum:=@rownum+1 AS seq FROM information_schema.COLUMNS, (SELECT @rownum:=0) r LIMIT 100000) t;
EOF

./pt-online-schema-change \
  --host=127.0.0.1  \
  --port=3306 \
  --user=mydba \
  --password=Mydba123! \
  --alter "MODIFY COLUMN description VARCHAR(255) COLLATE utf8mb4_unicode_ci NOT NULL" \
  --recursion-method=none \
  --execute \
  D=mytest,t=big_table

 
show create table mytest.big_table; 로 확인해보면 collate 가 변경되어있다. 


# alter table 방식과 비교
: 락은 거의 잡지않지만 수행시간 길어지고 바이너리로그 사용량이 많아진다.
pt-osc는 분산되게 로그를 쓰지만 insert 문은 큰거 하나의 파일을 만든다
 
# 한계
병렬처리를 지원하지 않는데, 이는 pt-osc가 범용처리 목적으로 설계된 탓이다.


 

 
mysql 은 문자열의 저장 방식을 character set 과 collate 로 지정할수가 있다.
 
#  character set
문자저장 인코딩 체계
utf8mb4  4byte 지원 => 이모티콘 가능
utf8mb3 는 불가, 일부 지원안됨
 
#  collate 
collate는 비교, 정렬 기준 character set 에 종속적인 부분이 있다. 
문자형 타입에만 한정, 날짜형, 숫자형 과는 무관
- collate 종류의 의미 

ai (accent insensitive)
ci (case insensitive)
general 
bin (binary)
0900 : 버전 
 
 - 테이블 collate 변경 방법  

1) modify로 개별 컬럼만 변경 
 ex) ALTER TABLE aaa MODIFY COLUMN colA VARCHAR(255) 
      CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
2) 테이블 속성만 변경 
 ex) ALTER TABLE aaa DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  => 테이블의 속성은 변경되지만 기존 데이터 변경되지 않고, 추가되는 컬럼만 이 속성을 따름. 
3) convert
  기존 데이터도 변환하여 저장. lock 을 수반. 대량 테이블은 오랜 시간 걸림
 
4) pt-onlie-schema-change
  lock 없이 온라인으로 템프테이블에 데이터 카피후  rename 방식

 
# collate 변경시 이슈
 서로다른 collate 컬럼으로 조인을 걸때 에러가 날수 있다. 
collate 의 특징을 알고 처음 설계단계에서 지정 collate 를 표준으로 쓰는 것이 중요. 

collate 변경은 결국 인덱스를 재생성 하는 과정.
collate 는 테이블에 지정된 메타데이터일뿐 인덱스는 실제로 저장된형태로 가지고 있어서 재생성 작업이 필요하다. pk가 숫자형, 날짜형 칼럼이고 세컨더리 인덱스도 없다면 시간은 오래걸리지 않는다