SQL Linux fsync 버퍼된 IO (버퍼된 쓰기중 오류가 발생하였을때 파일은 유효할까?)

 

·       Version : SQL Server Linux

 

 

PostgreSQL에서 fsync() 오류처리는 안전하지 않으며 XFS에서 데이터 손실이  발생할 있다는 내용이 있다.

·       PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS : https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@mail.gmail.com

 

이번 포스트는  SQL Server에서도 Linux 동일한 문제가 발생하는지 유효성을 검증하는 내용으로,  SQL Server 경우 O_DIRECT 사용하기 때문에 PostgreSQL 같은 문제가 발생하지 않는다.

·       Direct I/O : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/global_file_system/s1-manage-direct-io

 

응용 프로그램이 버퍼된 쓰기를 수행하고 성공을 수신한다. (이는 안정된 미디어 파일 시스템 캐시에 데이터를 저장할 있음을 의미한다.) fsync/fdatasync 데이터가 안정적인 미디어에 저장되도록 하는데 사용된다. 안정적인 미디어 쓰기는 동기화 작업중에 발생하며 EIO 오류를 보고하는 여러가지 이유로 (디스크 공간부족, SAN 연결 끊김 ) 실패할 있다.

·       fsync/fdatasync : http://man7.org/linux/man-pages/man2/fdatasync.2.html

 

 

 

위의 PostgreSQL링크에 설명된 문제는 동기화에서 오류를 반환하지만 캐시된 페이지의 상태를 지울수 있다 것이다. 다음 동기화는 캐시된 쓰기가 안정적인 미디어로 플러시 되지 않지만 응용 프로그램에 알려졌다는 것을 의미하는 ESUCCESS 반환한다.

 

데이터베이스 응용프로그램이 백업 파일을 열어 파일 시스템 캐싱 (~_O_DIRECT) 허용한다고 가장헌다. SQL Server 작업을 수행하지 않으며  실제로 Linux SQL Server에서 작업을 수행할 없도록 했다.

1.       버퍼링된 I/O 사용하여 백업이 시작된다.

2.       백업이 진행되면서 파일 시스템 캐시에 쓰기가 발생한다.

3.       파일 시스템 캐시 쓰기가 발생하는 동안 동기화에 대한 외부 호출이 발생한다.

4.       백업에 속한 버퍼에서 동기화쓰기 오류가 발생한다. 데이터베이스 응용프로그램 외부의 응용 프로그램에서 동기화를 호출하여 데이터베이스 응용프로그램이 실패를 인식하지 못한다.

5.       백업이 끝나면 데이터베이스 응용 프로그램에서 fdatasync 실행하고 EIO 반호나하는 대신 ESUCCESS 반환된다.

6.       fdatasync 성공적으로 완료되면 미디어 백업이 안정적으로 강화되고 데이터베이스 응용 프로그램이 트랜잭션 로그의 비활성 부분을 자른다.

7.       데이터베이스에 이상 트랜잭션 조작 또는 복구를 수행 적절한 로그 레코드가 없고, 일단 유효하다고 생각된 백업파일이 유효하지 않는다.

 

문제는 SQL Server 데이터베이스, 로그 백업파일에 영향을 미치지 않는다. SQL Server 파일 시스템 캐시를 무시하기 위해 O_DIRECT 사용하여 이러한 파일 형식을 연다. Linux SQL Server 강제 플러시 모드에서 실행 중인 경우에도 파일은 O_Direct 열리므로 문제가 발생하지 않는다.

 

 

[참고자료]

·       SQL Server Linux: fsync and Buffered I/O : https://blogs.msdn.microsoft.com/bobsql/2018/12/18/sql-server-linux-fsync-and-buffered-i-o/

 

 

2019-09-16 / Sungwook Kang / http://sungwookkang.com

 

 

SQL Server, SQL Linux, File System, Windows, Linux, fsync, fdatasync, O_Direct

SQL Server SQL Linux에서 인스턴스 파일 초기화 차이점

 

·       Version : SQL Server, SQL Server Linux

 

SQL Server 로그 파일 또는 데이터 파일이 증가하거나 새로 작성될때, 인스턴트 파일 초기화 작업을 진행한다. 이번 포스트에서는 인스턴스 파일이 초기화 될때, 기본 파일 시스템 구현과 Windows Linux 간의 동작 차이를 알아본다.

·       Database File Initialization : https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-instant-file-initialization?view=sql-server-2017

 

SQL Server 데이터 로그 파일을 만들거나 확장(증가)할때 아래 API 호출 한다.

·       CreateFile : 파일 작성 또는 열기

·       SetEndOfFile : 파일 크기를 설정하고 I/O 장치에서 공간을 확보

·       SetFileValidData : 유효한 데이터 크기 설정

 

파일이 로그 파일(LDF) 경우 SQL Server 알려진 패턴값을 할당된 공간에 쓴다. 데이터 파일 (MDF, NDF) 경우 SQL Server 인스턴스 파일 초기화 추적 플래그 1805 설정을 확인하여 할당된 공간에 패턴값을 쓸지 여부를 결정한다.

TF 1805 : 데이터 파일에 대한 인스턴스 파일 초기화를 비활성화 한다.

참고 : 스탬핑은 일반적으로 최적의 성능과 Windows Linux 파일 시스템 페이지 블록크기 정렬과 정렬을 위해 4MB 청크로 수행

 

[Windows]

Windows 파일 시스템(NTFS, RTFS)에는 파일을 즉시 초기화 하기 위한 개의 멤버키가 있다.

·       EOF : 파일 위치

·       VDL : 유효한 데이터 길이 위치

 

Empty File

파일이 처음 작성될  EOF VDL 모두 파일의 시작을 가리킨다.

·       EOF = 0

·       VLD = 0


     

 

SetEndOfFile

SetEndOfFile 파일을 확장하여 I/O 장치에서 공간을 확보하고 EOF 값을 조정한다. VLD 값은 변경되지 않은 상태로 유지된다.

·       EOF = 10G

·       VLD = 0

   

SetFileValidData

SetFileValidData VDL 이동하는데 사용된다. VDL 기록된 것으로 간주되는 경우(쓰기가 수행되지 않은 경우에도) VDL 오프셋 이전의 모든 데이터와 VDL 이전의 공간 읽기는 I/O 장치에서 오래된 데이터를 반환할  있다. VDL 이후의 데이터는 유효하지 않은 것으로 간주되며 읽기 요청에 대해 0 리턴된다.

·       EOF = 10GB

·       VDL = 1GB

참고 : 보안 고려사항과 관련된 내용은 위의Database File Initialization 문서를 참고한다.

 

Write beyond the current VDL (WriteFile*)

VDL 오프셋 이상으로 쓰기가 발생하면 WindowsVDL 이동하여 쓰기를 수용하고 이전 VDL 쓰기 요청 시작 사이의 오프셋에 0 쓴다.

·       EOF = 10GB

·       이전 VDL =1 GB

·       VDL = 5GB

 

Instant File Initialization (New File)

VDL 증분 변경 대신 SQL Server SetEndOfFile 빠른 할당 기능을 사용하고  동일한 오프셋으로 SetFileValidData 호출한다. VDL이전의 모든 데이터는 Windows 파일 시스템에 의해 쓰여진(유효한) 것으로 간주된다. 인스턴트 파일 초기화가 활성화  경우 Windows 0 쓰지 않으며 SQL Server 데이터 파일의 패턴을 스탬프 처리 하지 않는다. 내부 SQL Server 데이터베이스 할당 구조는 SQL Server 데이터 파일 할당  유효한 데이터 읽기 활동을 추적한다.

 

Instant File Initialization (Grow)

인스턴스 파일 초기화를 사용하여 파일을 확장하면  오프셋으로 SetEndOfFile  SetFileValidData 수행된다. Windows   오프셋과 이전 오프셋 사이의 데이터를 유요한 것으로 취급한다.

 

 

[Linux]

Fallocate(http://man7.org/linux/man-pages/man2/fallocate.2.html) 시스템 호출(ABI) 사용한 Linux 지원 파일 할당 Windows API호출은 아래와 같이 Linux ABI 호출에 매핑 된다.

·       CreateFile : Linux 사용

·       SetEndOfFile : Linux fallocate 사용

·       SetFileValidData : Linux Noop

 

Windows Linux 파일 시스템의 주요 차이점은 유효한 데이터 길이( VDL) 아닌 범위를 추적한다. Linux에서 범위에는 I/O 장치에 쓰여 졌는지 여부를 나타내는 플래그가 포함된다.

Empty File

파일이 처음 작성될   EOF= 0이고 포함 범위는 기록되지 않도록 (N)으로 설정된다. 쓰지 않은 범위의 읽기는 Linux에서 항상 0 반환한다. LinuxI/O 장치를 사용하지 않지만 단순히 쓰지 않는 범위로 추적된 공간에 대해 리턴 버퍼를 0으로 채운다.

 

힌트 : 익스텐트 크기  조정에 대해서는 Linux 파일 시스템 설명서를 확인한다. 기본 크기는 일반적으로 최적의 성능을 위해 SQL Server 페이지는8K  64K 범위 경계에  맞는 메모리 페이지 크기 경계(주로4K) 정렬된다.

 

SetEndOfFile

파일 크기 증가는 대체 호출로 발생한다. Linux I/O 장치에서 공간을 확보하고  EOF 추적 범위 메타 데이터를 설정하여 기록되지 않음을 나타낸다. Fallocate SetEndOfFile Windows 파일 시스템의 공간을 확보하는 것처럼 공간을 확보하여 대용량 파일을 빠르게 생성할  있다. 차이점은 SetFileValidData이다. Linux 실제 쓰기 없이 범위 추적을 쓰기 설정하는 기능을 제공하지 않는다.

 

 

성능 고려 사항 : 대상 파일 시스템에 대해 fallocate 지원되지 않으면 SQL Server ftruncate 사용한다. 이름과 달리 ftruncate ABI 파일을 늘리는데 사용될  있지만  프로비저닝된 조장이다.(공간은 메타데이터만 업데이트 되지 않는다.) ftruncate 필요한 경우 실제 공간을 확보하고 제공하기 위해 SQLPAL 파일에 0 쓴다. SQLPAL 프로세스에 대한 오류가 없고 읽기 동작이 없다.

 

Write

 번째 쓰기가 수행되면 범위에 대한 메타 데이터도 업데이트 된다. 쓰기  쓰기 되지 않은 데이터를 추적하기 위해 익스텐트를 분할하거나Linux 커널에 의해 확장된 쓰기는 디스크의 공간에 0 쓰므로 전체 익스텐트가 쓰기 된것으로 표시될  있다.

 

참고 : 대부분의 Linux 파일 시스템에서는  번의 쓰기 요청이 발생하지만 쓰기 크기  오프셋 정렬에 따라  커질수 있다. (데이터 파일 요청1개와 메타데이터 변경 요청 1)

 

 

Windows 에서 SetFileValidData 단일  메타 데이터 작업이다. VDL 설정되면 쓰기(순차 또는 임의) VDL == EOF 추가 메타 데이터 업데이트가 필요하지 않다. Linux에서 쓰기에는 데이터 쓰기 메타 데이터 쓰기가 필요한 익스텐트 업데이트가 필요하다. Linux 또는 Windows에서 가능한 빨리 파일을 쓰고 확장할 있다. 그러나 Linux에서 처음 쓰기를 수행하면 메타 데이터가 유지관리 된다.

·       데이터베이스에서 쓰기 속도가 중요한 경우 익스텐트 파일 초기화를 사용하고 번째 쓰기에 추가 오버헤드가 발생하도록 한다.

 

참고 : 대부분의 쓰기 작업은Checkpoint 또는 Lazy Write 같은 백그라운드 프로세스로 수행되므로 SQL Server에서 오버헤드를 숨기는 경우가 많다. 활성 SQL Server 세션에서 쓰기가 발생할 있으므로 대량 로드는 예외이다.

 

·        쓰기 속도를 늘릴수 있는 경우 -T1805 사용하면 데이터베이스가 쓰기 확장 중에 데이터파일 공간을 스탬핑 되도록 있다. 스탬핑은 청크로 최적화되어 있으며 번째 쓰기 데이터 메타 데이터 작업이 발생하는 쓰기 경로가 된다. 위치가 기록(스탬프) 되면 이상 추가 메타 데이터 쓰기가 필요하지 않다.

 

참고 : 파일 시스템이 fallocate 지원하지 않으면 SQLPAL 의해 파일에 0 기록된다. 로그 파일(LDF) 알려진 패턴(0으로 작성) 표시하며 SQLPAL 공간을 0으로 채울때 메타데이터가 이미 업데이트 되었으므로 데이터 파일에 대한 인스턴스 파일 초기화를 안전하게 유지할 있다.

 

[참고자료]

https://blogs.msdn.microsoft.com/bobsql/2018/12/10/sql-server-instant-file-initialization-setfilevaliddata-windows-vs-fallocate-linux/

 

 

2019-09-13 / Sungwook Kang / http://sungwookkang.com

 

 

SQL Server, SQL Linux, File System, Windows, Linux, SetFileValidData (Windows) vs fallocate (Linux), T1805, SetEndOfFile, SetFileValidData, VDL

 

SQL Linux 업그레이드

 

·         Version : SQL Linux, Ubuntu

 

SQL Linux 최신버전으로 업그레이드 하는 방법에 대해서 살펴본다. 필자는 Ubuntu SQL Linux 설치된 상태이다. SQL Linux 업그레이드 진행 하기전 전체 사용자 데이터베이스 백업을 진행한다. 만약 업그레이드가 잘못되어 데이터베이스를 복원해야 경우를 대비해서 백업본을 보관하는 것이 좋다.

 

서버 로컬 접속 또는  Putty등을 사용하여 Ubuntu 서버에 연결한다.필자의 경우 Putty 사용하여 Ubuntu 서버에 접속 하였다.

 

Ubuntu에서 기존에 실행되고 있는 SQL Linux 버전을 확인한다. Sqlcmd 유틸리티를 사용하여 SQL Linux 연결하여 정보를 확인 있다. (Sqlcmd외에도 다양한 연결방법이 있으니 sqlcmd 사용할 필요는 없다.)

sqlcmd -S localhost -U sa

 

SELECT @@VERSION

GO

 

 

“apt-get” 명령을 사용하여 설치된 패키지 mssql-server 세부 사항을 확인할 수도 있다. apt-get 유틸리티는 Ubuntu APT(Advanced Packaging Tool)라이브러리를 사용하여 소프트웨어 패키지 설치, 기존 소프트웨어 패지키 제거, 기존 소프트웨어 패키지 업그레이드 등에 사용되는 무료 패키지 관리 명령어 프로그램이다. 아래 명령을 사용하여 mssql-server 버전, 체크섬 크기, 설치된 크기, 카테고리 간단한 설명과 함께 패치지 정보를 확인할 있다.

apt-cache show mssql-server

 

 

SQL Server 업그레이드 있는 사용가능한 업데이트 파일이 있는지 확인한다. 필요한 작업은 아니지만 업그레이드 프로세스를 이해하는데 도움이 된기 때문에 간단히 살펴본다. 명령은 설치된 모든 패키지에 대해 사용가능한 업데이트를 표시한다.

apt-get --just-print upgrade

 

 

현재 mssql-server 보류중인 업데이트가 있으므로 apt-get update 실행하여 /etc/apt/sources.list 파일에 지정된 소스에서 패키지 인덱스 파일을 동기화 한다. Update 명령은 패키지 인덱스 파일을 최신 버전으로 업데이트 한다. 아래 명령을 사용하여 패키지를 업데이트 한다.

sudo apt-get update

 

패키지 인데스 업데이트가 완료 되었으면 아래 명령을다시 실행하여 사용가능한 업데이트를 확인한다. 아래 스크린샷에서는 개의 패키지가 있음을 수있다. 하나는 이전 버전이고 다른 하나는 mssql-server 업그레이드하기 위해 적용해야하는 새로운 업데이트이다.

apt-cache show mssql-server

 

 

사용가능한 최신버전으로 업레이드하기 위해 아래 명령을 실행한다. 아래 명령은 최신 패키지를 다운로드 하고 /opt/mssql 있는 바이너리를 교체한다. 작업은 SQL 엔진을 교체하는 작업으로  사용자 데이터베이스에는 영향을 미치지 않지만 혹시 발생할 오류를 대비해서 처음 언급 한것처럼 백업을 것을 권장한다.

sudo apt-get install mssql-server

 

 

작업이 완료되면 SQL Server 빈드 버전이 14.0.3026.27에서 14.0.3029.16 업그레이드 것을 확인할 있다.

 

 

[참고자료]

https://www.mssqltips.com/sqlservertip/4647/upgrading-sql-server-running-on-ubuntu-to-latest-update/

 

 

2018-06-21 / Sungwook Kang / http://sqlmvp.kr

 

SQL Server, SQL Linux, SQL Upgrade, apt-get, apt-get update, apt-get install, 리눅스, linux,

'SQL Server > SQL on Linux' 카테고리의 다른 글

SQL Linux Instance Name 변경  (0) 2019.03.25
SQL Linux 업그레이드  (0) 2019.03.25
SQL Linux에서 Job Agent 설치  (0) 2017.09.13
SQL Linux에서 Windows SQL 백업 파일 복원  (0) 2017.09.13
Linux에서 Network I/O 확인  (0) 2017.09.13
SQL Linux에서traceflag 활성화  (0) 2017.09.13

MySQL/MariaDB Memory 모니터링

 

·      Version : MySQL 5.7.21, Ubuntu 16.0.4

 

Memory 사용률은 모든 운영체제에서 중요한 모니터링 지표이다. 다양한 어플리케이션이 서버에서 실행되면서 실제 물리메모리를 초과하는 메모리 요구가 발생할 있기 때문에 메모리 모니터링도 중요하다. 실제 데이터베이스의 경우 메모리가 부족하여 성능저하가 크게 발생하는 경우가 많다.

 

아래 명령어는 Unbuntu Linux에서 5 간격으로 메모리 사용량을 확인하는 명령이다.

watch -n 5 free –m

 


 

리눅스는 메모리의 효율적인 운영을 위해 전체 메모리에서 미리  Buffers + Cached 값을 자동으로 할당해 놓는다. 만일 어플리케이션에서 메모리가 필요할 경우 Cached 할당된 메모리를 자동으로 반환해 어플리케이션에 할당한다.

 

MySQL 서버는 다양한 종류의 메모리 버퍼(메모리 캐시) 사용한다. 사용영역에 따라 크게 전역과 지역으로 나눌 있다.

·       MySQL/MariaDB 아키텍처 메모리 할당 사용 구조 : http://sqlmvp.kr/220404814981

전역 메모리 (모든 커넥션 또는 스레드에서 공유)

지역메모리 (세션별로 할당, 공유하지 않음)

·       InnoDB Buffer pool

·       MyISAM key cache

·       Join buffer

·       Sort buffer

·       Read buffer

 

전체 메모리 사용량을 예상하여 할당하려면 아래와 같은 공식을 사용한다.

전역 메모리 사용량 + (지역적 메모리 사용량 X 최대 동시 커넥션 )

 

만약 물리 메모리 대비 InnoDB 버퍼풀 크기 비율을 과도하게 높게 하였을때 활성 커넥션(Active DB Connections) 증가로 세션 단위의 메모리 사용량이 증가한다면 MySQL 서버가 사용하는 전체 메모리는 물리메모리를 초과할 있으며 서버의 성능저하로 이어질 있다. 따라서 아래와 같은 가이드를 제공하여 성능 저하를 예방할 있다.

·       운영체제가 사용하는 적정 메모리 용량을 제외한 Buffer pool 할당

·       MySQL 서버에서 제공하는 Max Connection 제한

·       Max Connection 만큼 세션이 증가할 있으므로 세션별로 사용해야 하는 메모리 사용량 제한

·       물리 메모리를 초과하지 않는 범위에서 MySQL 서버가 전역적으로 사용해야하는 메모리 영역에 대한 최대 사용랑 제한

 

메모리 관련 설정을 메모리 사용량에 영향을 있는 변수는 약간의 유휴 메모리를 유지될 있게 설정하는 것을 권장한다.

·       MySQL/MariaDB Memory 관련 설정 변수 : http://sqlmvp.kr/220365937569

 

Swap 메모리가 빈번한 경우 서버에서 실행되는 어플리케이션이 메모리를 적절하게 사용하지 못하거나 물리 메모리가 부족하다는 것을 의미하기 때문에 Swap 지수가 0보다 경우 어느 어플리케이션이 메모리를 많이 사용하는지 확인이 필요하다.

 

 

[참고자료]

·       How MySQL Uses Memory : https://dev.mysql.com/doc/refman/5.7/en/memory-use.html

 

 

2018-03-27 / 강성욱 / http://sqlmvp.kr / http://sqlangeles.com

 

MySQL, MariaDB, linux, Memory 모니터링, watch, InnoDB Buffer pool, MySQL 메모리 사용량, 전역 메모리, 지역 메모리, 세션 메모리, Max connection



+ Recent posts