개발 노트

Mysql을 통해 환경을 세팅하는 중 가장 흔하게 만날 수 있는 오류가 하나 있다.

아래와 같은 오류인데, 이 오류가 무엇인지! 해결방법은 무엇인지 알아보자.

Client does not support authentication protocol requested by server; consider upgrading MySQL client

오류의 원인

Mtysql 8부터는 Pluggable Authentication methods를 지원한다. 기본적으로 Caching_sha2_password가 사용이 되고,

우리가 흔히 사용하는 user/password 방법인 mysql_native_password를 사용하는 방법은 default가 아니다.

당연히 SHA2와 같은 암호화 알고리즘을 쓰는 방법은 단순히 Password를 사용하는 방법보다 안전하다.

하지만 Mysqljs에서는 mysql_native_password만 지원을 하기 때문에 위와 같은 문제가 발생한다.

mysqljs를 꼭!! 반드시!! 사용해야한다면 아래 1번 해결방법을 따라하면 된다.

해결방법

해결방법1

특정 사용자에 대해서 mysql_native_password 접근을 허용하면 된다.

아래 SQL문으로 접근을 허용 할 수 있다.

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password '비밀번호'

매우 간단하고 효과적인 방법이다. 그리고 Mysqljs에 의존적인 라이브러리를 사용하고 있는 경우 어쩔 수 없이 선택해야 하는 방법이기도 하다. 하지만 이 방법을 사용할때 한가지는 알고있으면 좋을 것 같다.

"더 Secure한 방법이 있지만, 나는 지금 그 이점을 버리고 내가 편한 방법으로 진행중이다"

해결방법2

오래된 Mysqljs를 버리고 다른 Library로 교체

https://www.npmjs.com/package/mysql2

https://dev.mysql.com/doc/dev/connector-nodejs/8.0/

mysql2의 경우 mysql js를 fork하여 발전시킨 오픈소스 라이브러리이고,

connector-nodejs는 Oracle에서 개발, 유지중인 nodejs mysql driver이다.

cirros 이미지로 서버(인스턴스)를 실행했는데

서버는 Active인데 ping 과 같은 기능이 동작하지 않음.

Openstack dashboard에서 인스턴스의 console 로 가서 확인해보니

No bootable device

로컬에서 tsc 빌드는 정상적으로 되는데,

배포시 원격 서버에서 빌드를 할때 문제가 발생하였다.

(지금까지 빌드부터 배포까지 잘 되고 있었는데... 갑자기 발생하였다 ㅠㅠ)

정확히 어떤 환경 때문에 발생하게 되었는지는 파악하지 못했지만, tsconfig를 수정하여 문제를 해결 할 수 있었다.

오류 내용은 다음과 같다.

Property 'asyncIterator' does not exist on type 'SymbolConstructor'.

Cannot find name 'AsyncIterableIterator'. Do you need to change your target library? Try changing the `lib` compiler option to 'es2018' or later.

해결 방법은 tsconfig.json 파일에 해당 내용을 추가해주었다.

"compilerOptions": {

  "lib": [

    "esnext.asynciterable"

  ]

}

기존에 있던 lib에서 "esnext.asynciterable"를 추가하였고,

정상적으로 빌드, 배포 되었다.

golang 1.14

증상

운영중인 서버 상태를 모니터링 하는데 Memery 사용률이 50% 이상인 상태로 2시간이 넘게 지속되는 현상이 발생.

하지만 CPU 사용량은 3% 미만이고 트래픽이 많이 발생하지 않는 상태였음.

로그를 확인해보니 중간에 트래픽이 몰리면서 CPU 사용량이 30% 이상으로 지속되면서 메모리 사용량이 늘어난 것을 확인함.

문제 해결

최초에는 'Memory leak이 있나?' 생각했지만 6개월 이상 정상적으로 동작하던 서버였기 때문에 Memory leak을 찾기 전 관련 Issue를 찾아보기 위하여 Stack overflow와 Golang 커뮤니티를 검색함.

결론

Memory leak이 아님!

golang에서 OS에서 할당받은 메모리를 release해주지 않던것이 해당 증상의 원인이었음.

Memory를 할당 받는 것은 비용이 크기 때문에 반환을 하지 않고, golang에서 해당 메모리를 계속 들고 있게됨.(OS에서 Memory가 필요하면 반납함)

만약 강제로 Memory를 반납하고 싶다면 

debug.FressOSMemory()

를 사용 할 수 있음

추가 사항

Autoscaling 정책에 Memory 점유율도 포함을 시켜놓고 있었는데, 

해당 서버에서는 컨테이너화된 Go 서버만 돌고 있기 때문에 Memory 점유율에 대한 정책을 조절하여 위와 같은 상황에서 Scale-out되는 경우가 덜 발생하도록 함.

Golang 1.16에서는 Memory 계산 방법이 변경되어 위와 같은 증상이 발생하지 않는다고 하는데, Golang 버전 변경을 아직 해보지 않아서 확인해보지 못함.(나중에 해봐야지...)

Tibero에 dump 파일을 import하는 도중에 발생.

Table Space의 경우 아래와 같이 AutoExtend를 On 했는데도 문제가 발생함.

CREATE TABLESPACE TEST_01 DATAFILE 'TEST.dbf' SIZE 1G AUTOECTEND ON;

문제

SELECT * FROM dba_data_files WHERE TABLESPACE_NAME='TEST_01';

을 통해 조회시 데이터파일 용량이 32G임을 확인.

Tibero menual을 확인해본 결과 Data File의 용량은 32GB가 최대치이고, BIGFILE 키워드를 사용하여 Table space를 생성 할 시 32TB까지 가능하다고 함.

하지만 메뉴얼대로

CREATE BIGFILE TABLESPACE TEST_01 DATAFILE 'TEST.dbf' SIZE 1G AUTOECTEND ON;

을 입력하는 경우 Syntax Error가 발생.(Licence가 trial이라서 안되는것인가.....?)

해결

Dump파일에서 사용중인 Table space의 크기를 알고 있는 상태라 충분한 크기이 data file을 할당해줌

CREATE TABLESPACE TEST_01 DATAFILE 

'TEST_001.dbf' SIZE 32G AUTOECTEND ON,

'TEST_002.dbf' SIZE 32G AUTOECTEND ON,

'TEST_003.dbf' SIZE 32G AUTOECTEND ON,

'TEST_004.dbf' SIZE 32G AUTOECTEND ON;

위와 같은 방법대로 여러개의 Datafile을 만들도록 함.

미해결 문제

CREATE BIGFILE TABLESPACE 만 동작한다면 쉽게 해결이 가능했을 것 같은데, 아직 안되는 원인을 찾지 못하였음.