Azure Database for MySQL - 유연한 서버의 서버 매개 변수
적용 대상:
Azure Database for MySQL - 유연한 서버
이 문서에서는 Azure Database for MySQL - 유연한 서버에서 서버 매개 변수를 구성하는 데 있어서의 고려 사항 및 지침을 제공합니다.
참고 항목
이 문서에는 Microsoft에서 더 이상 사용하지 않는 용어인 슬레이브라는 용어에 대한 참조가 포함되어 있습니다. 소프트웨어에서 용어가 제거되면 이 문서에서 해당 용어가 제거됩니다.
서버 변수란?
MySQL 엔진은 엔진 동작을 구성 및 조정하는 데 사용할 수 있는 여러 서버 변수/매개 변수를 제공합니다. 일부 매개 변수는 런타임 중에 동적으로 설정할 수 있으며, "정적"이기 때문에 서버를 다시 시작해야 적용되는 매개 변수도 있습니다.
Azure Database for MySQL 유연한 서버는 Azure Portal과 Azure CLI를 사용하여 워크로드의 요구 사항에 맞게 다양한 MySQL 서버 매개 변수의 값을 변경하는 기능을 제공합니다.
구성 가능한 서버 매개 변수
서버 매개 변수를 사용하여 Azure Database for MySQL 유연한 서버 구성을 관리할 수 있습니다. 서버 매개 변수는 서버를 만들 때 기본/권장 값으로 구성됩니다. Azure Portal의 서버 매개 변수 블레이드에는 수정 가능/불가능한 서버 매개 변수가 모두 표시됩니다. 수정 불가능한 서버 매개 변수는 회색으로 표시됩니다.
지원되는 서버 매개 변수 목록은 계속 확장됩니다. Azure Portal의 서버 매개 변수 탭을 사용하여 전체 목록을 보고 서버 매개 변수 값을 구성할 수 있습니다.
일반적으로 업데이트되는 여러 서버 매개 변수의 제한에 대해 자세히 알아보려면 다음 섹션을 참조하세요. 제한은 서버의 컴퓨팅 계층 및 크기(vCore)에 따라 결정됩니다.
참고 항목
- 포털을 사용하여 정적 서버 매개 변수를 수정하는 경우 변경 내용을 적용하려면 서버를 다시 시작해야 합니다. 자동화 스크립트(ARM 템플릿, Terraform, Azure CLI 등과 같은 도구 사용)를 사용하는 경우 만들기 환경의 일부로 구성을 변경하더라도 설정이 적용되도록 서비스를 다시 시작하는 프로비전이 스크립트에 있어야 합니다.
- 사용 중인 환경에서 수정할 수 없는 서버 매개 변수를 수정하려면 UserVoice 항목을 열거나, 이미 해당 피드백이 있는 경우에는 투표를 통해 Microsoft에서 우선 순위 지정에 도움이 되도록 합니다.
lower_case_table_names
MySQL 버전 5.7에서는 1이 Azure Database for MySQL 유연한 서버의 기본값입니다. 중요한 점은 지원되는 값을 2로 변경할 수는 있지만 2에서 1로 되돌리는 것은 불가능하다는 점입니다. 기본값 변경에 도움이 필요하면 지원 팀에 문의하세요. MySQL 버전 8.0 이상에서는 서버 초기화 시에만 lower_case_table_names를 구성할 수 있습니다. 자세히 알아보기. 서버 초기화가 끝난 다음에 lower_case_table_names 설정을 변경하는 것은 금지됩니다. MySQL 버전 8.0에서는 1이 Azure Database for MySQL 유연한 서버의 기본값입니다. MySQL 버전 8.0에서는 Azure Database for MySQL 유연한 서버 값으로 1과 2를 지원합니다. 서버 제작 중에 기본값 변경과 관련해 도움이 필요한 경우 지원 팀에 문의합니다.
innodb_tmpdir
Azure Database for MySQL 유연한 서버의 innodb_tmpdir 매개 변수는 다시 빌드하는 온라인 ALTER TABLE 작업 중에 생성된 임시 정렬 파일용 디렉터리를 재정의하는 데 사용됩니다. innodb_tmpdir의 기본값은 /mnt/temp입니다. 이 위치는 임시 스토리지 SSD에 해당하며 서버별 컴퓨팅 크기에 GiB로 사용할 수 있습니다. 이 위치는 공간이 크게 필요 없는 작업에 적합합니다.
공간이 더 필요하면 innodb_tmpdir를 /app/work/tmpdir로 설정하면 됩니다. 이렇게 하면 Azure Database for MySQL 유연한 서버에서 사용할 수 있는 스토리지 용량을 활용합니다. 이 방식은 임시 스토리지가 더 필요한, 규모가 더 큰 작업에 유용할 수 있습니다.
/app/work/tmpdir를 활용하면 기본 임시 스토리지(SSD)/mnt/temp에 비해 성능이 저하된다는 점은 알고 있어야 합니다. 작업의 구체적인 요구 사항에 맞춰 선택해야 합니다.
innodb_tmpdir에 입력된 정보는 /mnt/temp가 공통적으로 기본값일 때 innodb_temp_tablespaces_dir, tmpdir, slave_load_tmpdir 매개 변수에 적용할 수 있으며, 대체 디렉터리인 /app/work/tmpdir는 더 많은 임시 스토리지 구성이 가능하지만 구체적인 작업 요구 사항에 따라 장단점이 존재합니다.
log_bin_trust_function_creators
Azure Database for MySQL 유연한 서버에서는 이진 로그를 항상 사용하도록 설정되며, 이는 log_bin이 ON으로 설정된다는 의미입니다. log_bin_trust_function_creators는 유연한 서버에서 기본적으로 ON으로 설정됩니다.
이진 로깅 형식은 항상 행이고 서버에 대한 모든 연결은 항상 행 기반 이진 로깅을 사용합니다. 행 기반 이진 로깅을 사용하면 보안 문제가 없고 이진 로깅이 중단되지 않으므로 log_bin_trust_function_creators를 안전하게 ON으로 유지해 둘 수 있습니다.
[log_bin_trust_function_creators]가 OFF로 설정된 경우 트리거를 만들려고 하면 슈퍼 권한이 없고 이진 로깅이 사용 설정되었습니다(덜 안전한 log_bin_trust_function_creators 변수를 사용하는 것이 좋습니다)와 유사한 오류가 발생할 수 있습니다.
innodb_buffer_pool_size
이 매개 변수에 대한 자세한 내용은 MySQL 설명서를 참조하세요.
| 가격 책정 계층 | vCore | 메모리 크기(GiB) | 기본값(바이트) | 최솟값(바이트) | 최댓값(바이트) |
|---|---|---|---|---|---|
| 버스트 가능(B1s) | 1 | 1 | 134217728 | 33554432 | 134217728 |
| 버스트 가능(B1ms) | 1 | 2 | 536870912 | 134217728 | 536870912 |
| 버스트 가능 | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| 범용 | 2 | 8 | 5368709120 | 134217728 | 5368709120 |
| 범용 | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| 범용 | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| 범용 | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
| 범용 | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
| 범용 | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
| 범용 | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
| 중요 비즈니스용 | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
| 중요 비즈니스용 | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
| 중요 비즈니스용 | 8 | 64 | 51539607552 | 134217728 | 51539607552 |
| 중요 비즈니스용 | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
| 중요 비즈니스용 | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
| 중요 비즈니스용 | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
| 중요 비즈니스용 | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
innodb_file_per_table
MySQL은 테이블을 만드는 동안 제공된 구성에 따라 InnoDB 테이블을 다른 테이블스페이스에 저장합니다. 시스템 테이블스페이스는 InnoDB 데이터 사전의 스토리지 영역입니다. file-per-table 테이블스페이스에는 단일 InnoDB 테이블에 대한 데이터 및 인덱스를 포함하며 파일 시스템에 자체 데이터 파일로 저장됩니다. 이 동작은 innodb_file_per_table 서버 매개 변수에 의해 제어됩니다. innodb_file_per_table을 OFF로 설정하면 InnoDB가 시스템 테이블스페이스에 테이블을 만듭니다. 그렇지 않으면 InnoDB는 file-per-table 테이블스페이스에 테이블을 만듭니다.
Azure Database for MySQL 유연한 서버는 단일 데이터 파일에서 최대 4TB를 지원합니다. 데이터베이스 크기가 4TB보다 큰 경우 innodb_file_per_table 테이블스페이스에 테이블을 만들어야 합니다. 단일 테이블 크기가 4TB보다 큰 경우에는 파티션 테이블을 사용해야 합니다.
innodb_log_file_size
innodb_log_file_size는 로그 그룹에 있는 각 로그 파일의 크기(바이트)입니다. 결합된 로그 파일(innodb_log_file_size * innodb_log_files_in_group)의 크기는 512GB보다 약간 작은 최댓값을 초과할 수 없습니다. 로그 파일 크기가 더 크면 성능에는 더 좋지만, 충돌 후 복구 시간이 길어진다는 단점이 있습니다. 드물게 충돌 복구가 발생하는 경우 복구 시간과 최대 작업 중 처리량 최대화의 균형을 유지해야 합니다. 이로 인해 다시 시작하는 시간이 더 길어질 수도 있습니다. Azure Database for MySQL 유연한 서버에서는 innodb_log_size 값을 256MB, 512MB, 1GB 또는 2GB로 구성할 수 있습니다. 매개 변수가 정적이며 다시 시작해야 합니다.
참고 항목
innodb_log_file_size 매개 변수를 기본값에서 변경한 경우 "show global status like 'innodb_buffer_pool_pages_dirty'" 값이 다시 시작 지연을 방지하기 위해 30초간 0으로 유지되는지 확인합니다.
max_connections
max_connection 값은 서버의 메모리 크기에 따라 결정됩니다.
| 가격 책정 계층 | vCore | 메모리 크기(GiB) | 기본값 | 최소값 | 최대값 |
|---|---|---|---|---|---|
| 버스트 가능(B1s) | 1 | 1 | 85 | 10 | 171 |
| 버스트 가능(B1ms) | 1 | 2 | 171 | 10 | 341 |
| 버스트 가능 | 2 | 4 | 341 | 10 | 683 |
| 범용 | 2 | 8 | 683 | 10 | 1365 |
| 범용 | 4 | 16 | 1365 | 10 | 2731 |
| 범용 | 8 | 32 | 2731 | 10 | 5461 |
| 범용 | 16 | 64 | 5461 | 10 | 10923 |
| 범용 | 32 | 128 | 10923 | 10 | 21845 |
| 범용 | 48 | 192 | 16384 | 10 | 32768 |
| 범용 | 64 | 256 | 21845 | 10 | 43691 |
| 중요 비즈니스용 | 2 | 16 | 1365 | 10 | 2731 |
| 중요 비즈니스용 | 4 | 32 | 2731 | 10 | 5461 |
| 중요 비즈니스용 | 8 | 64 | 5461 | 10 | 10923 |
| 중요 비즈니스용 | 16 | 128 | 10923 | 10 | 21845 |
| 중요 비즈니스용 | 32 | 256 | 21845 | 10 | 43691 |
| 중요 비즈니스용 | 48 | 384 | 32768 | 10 | 65536 |
| 중요 비즈니스용 | 64 | 504 | 43008 | 10 | 86016 |
연결 한도를 초과하면 다음과 같은 오류가 발생할 수 있습니다.
오류 1040(08004): 너무 많은 연결이 있습니다.
Important
최상의 환경을 위해 ProxySQL과 같은 연결 풀러를 사용하여 연결을 효율적으로 관리하는 것이 좋습니다.
MySQL에 대한 새 클라이언트 연결을 만들려면 시간이 필요하며, 일단 설정되면 이러한 연결은 유휴 상태일 때에도 데이터베이스 리소스를 차지합니다. 대부분의 애플리케이션은 많은 단기 연결을 요청합니다. 이는 이러한 상황을 복잡하게 만듭니다. 결과적으로 실제 워크로드에 사용할 수 있는 리소스의 성능이 저하됩니다. 유휴 연결을 줄이고 기존 연결을 다시 사용하는 연결 풀러는 이러한 문제를 방지하는 데 도움이 됩니다. ProxySQL 설정에 대해 알아보려면 블로그 게시물을 방문하세요.
참고 항목
ProxySQL은 오픈 소스 커뮤니티 도구입니다. 최상의 노력을 기준으로 Microsoft에서 지원됩니다. 신뢰할 수 있는 지침을 사용하여 프로덕션 지원을 받으려면 평가 후 ProxySQL 제품 지원에 문의할 수 있습니다.
innodb_strict_mode
"행 크기가 너무 큼(> 8126)"과 유사한 오류가 표시되면 innodb_strict_mode 매개 변수를 비활성화할 수 있습니다. 서버 매개 변수 innodb_strict_mode는 서버 수준에서 전역 수정이 허용되지 않는데, 행 데이터 크기가 8k보다 큰 경우 데이터가 오류 없이도 잘려나가 잠재적인 데이터 손실로 이어질 수 있기 때문입니다. 페이지 크기 제한에 맞춰 스키마를 수정하는 것이 좋습니다.
이 매개 변수는 init_connect를 사용하여 세션 수준에서 설정할 수 있습니다. 세션 수준에서 innodb_strict_mode를 설정하려면 설정 매개 변수가 목록에 없음을 참조하세요.
참고 항목
읽기 복제본 서버가 있는 경우 소스 서버에서 세션 수준으로 innodb_strict_mode를 OFF로 설정하면 복제가 중단됩니다. 읽기 복제본이 있는 경우 매개 변수를 ON으로 유지하는 것이 좋습니다.
time_zone
초기 배포 시 Azure Database for MySQL 유연한 서버 인스턴스는 표준 시간대 정보에 대한 시스템 테이블을 포함하지만 이러한 테이블은 채워지지 않습니다. MySQL 명령줄 또는 MySQL Workbench와 같은 도구에서 mysql.az_load_timezone 저장 프로시저를 호출하여 표준 시간대 테이블을 채울 수 있습니다. 저장 프로시저를 호출하고 글로벌 또는 세션 수준 표준 시간대를 설정하는 방법은 Azure Portal 또는 Azure CLI 문서를 참조하세요.
binlog_expire_logs_seconds
Azure Database for MySQL 유연한 서버에서 이 매개 변수는 서비스가 이진 로그 파일을 제거하기 전에 대기하는 시간(초)을 지정합니다.
이진 로그에는 테이블 생성 작업 또는 테이블 데이터 변경과 같은 데이터베이스 변경 사항을 설명하는 ‘이벤트’가 포함됩니다. 또한 잠재적으로 변경했을 수 있는 명령문에 대한 이벤트도 포함합니다. 이진 로그는 주로 복제 및 데이터 복구 작업의 두 가지 목적으로 사용됩니다. 일반적으로 이진 로그는 핸들이 서비스, 백업 또는 복제 세트에서 해제되는 즉시 제거됩니다. 복제본이 여러 개인 경우 이진 파일 로그는 가장 느린 복제본이 제거되기 전에 변경 내용을 읽기까지 기다립니다. 이진 로그를 좀 더 오래 유지하려면 binlog_expire_logs_seconds 매개 변수를 구성하면 됩니다. binlog_expire_logs_seconds가 기본값인 0으로 설정되면 이진 로그에 대한 핸들이 해제되는 즉시 제거됩니다. binlog_expire_logs_seconds > 0이면 제거하기 전에 구성된 초까지 기다립니다. Azure Database for MySQL 유연한 서버의 경우 이진 파일의 백업 및 읽기 복제본 제거와 같은 관리 기능은 내부적으로 처리됩니다. Azure Database for MySQL 유연한 서버에서 데이터 출력을 복제할 때 복제본이 기본에서 변경 사항을 읽기 전에 이진 로그를 제거하지 않도록 이 매개 변수를 기본에서 설정해야 합니다. binlog_expire_logs_seconds를 더 높은 값으로 설정하면 이진 로그가 충분히 빨리 제거되지 않고 스토리지 청구가 증가할 수 있습니다.
event_scheduler
Azure Database for MySQL 유연한 서버에서 event_schedule 서버 매개 변수는 이벤트 만들기, 예약 및 실행을 관리합니다. 즉, 일정에 따라 실행되는 작업은 특수 이벤트 스케줄러 스레드에 의해 실행됩니다. event_scheduler 매개 변수가 ON으로 설정되면 이벤트 스케줄러 스레드가 SHOW PROCESSLIST 출력에 디먼 프로세스로 나열됩니다. 다음 SQL 구문을 사용하여 이벤트를 만들고 예약할 수 있습니다.
CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;
참고 항목
이벤트 만들기에 대한 자세한 내용은 여기에서 MySQL Event Scheduler 설명서를 참조하세요.
event_scheduler 서버 매개 변수 구성
다음 시나리오에서는 Azure Database for MySQL 유연한 서버에서 event_scheduler 매개 변수를 사용하는 한 가지 방법을 보여 줍니다. 시나리오를 설명하기 위해 다음 예인 간단한 테이블을 고려합니다.
mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| CreatedAt | timestamp | YES | | NULL | |
| CreatedBy | varchar(16) | YES | | NULL | |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)
Azure Database for MySQL 유연한 서버에서 event_scheduler 서버 매개 변수를 구성하려면 다음 단계를 수행합니다.
Azure Portal에서 Azure Database for MySQL 유연한 서버 인스턴스로 이동한 다음, 설정에서 서버 매개 변수를 선택합니다.
서버 매개 변수 블레이드에서
event_scheduler를 검색하고 VALUE 드롭다운 목록에서 ON을 선택한 다음 저장을 선택합니다.참고 항목
동적 서버 매개 변수 구성 변경 내용은 다시 시작하지 않고 배포됩니다.
그런 다음, 이벤트를 만들기 위해 Azure Database for MySQL 유연한 서버 인스턴스에 연결하고 다음 SQL 명령을 실행할 수 있습니다.
CREATE EVENT test_event_01 ON SCHEDULE EVERY 1 MINUTE STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR COMMENT ‘Inserting record into the table tab1 with current timestamp’ DO INSERT INTO tab1(id,createdAt,createdBy) VALUES('',NOW(),CURRENT_USER());Event Scheduler 세부 정보를 보려면 다음 SQL 문을 실행합니다.
SHOW EVENTS;다음과 같은 출력이 표시됩니다.
mysql> show events; +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | Db | Name | Definer | Time zone | Type | Execute at | Interval value | Interval field | Starts | Ends | Status | Originator | character_set_client | collation_connection | Database Collation | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | db1 | test_event_01 | azureuser@% | SYSTEM | RECURRING | NULL | 1 | MINUTE | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1 | latin1_swedish_ci | latin1_swedish_ci | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ 1 row in set (0.23 sec)몇 분 후에 테이블의 행을 쿼리하여 구성한
event_scheduler매개 변수에 따라 매분 삽입된 행 보기를 시작합니다.mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | +----+---------------------+-------------+ 4 rows in set (0.23 sec)한 시간 후에 테이블에서 사례에서
event_scheduler가 구성되는 한 시간 동안 Select 문을 실행하여 매분 테이블에 삽입된 값의 전체 결과를 확인합니다.mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | | 5 | 2023-04-05 14:51:04 | azureuser@% | | 6 | 2023-04-05 14:52:04 | azureuser@% | ..< 50 lines trimmed to compact output >.. | 56 | 2023-04-05 15:42:04 | azureuser@% | | 57 | 2023-04-05 15:43:04 | azureuser@% | | 58 | 2023-04-05 15:44:04 | azureuser@% | | 59 | 2023-04-05 15:45:04 | azureuser@% | | 60 | 2023-04-05 15:46:04 | azureuser@% | | 61 | 2023-04-05 15:47:04 | azureuser@% | +----+---------------------+-------------+ 61 rows in set (0.23 sec)
기타 시나리오
특정 시나리오의 요구 사항에 따라 이벤트를 설정할 수 있습니다. 다른 시간 간격으로 실행되도록 SQL 문을 예약하는 몇 가지 유사한 예는 다음과 같습니다.
지금 SQL 문을 실행하고 하루에 한 번씩 끝없이 반복합니다.
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;
매시간 끝없이 SQL 문을 실행합니다.
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;
끝없이 매일 SQL 문을 실행합니다.
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;
제한 사항
고가용성이 구성된 서버의 경우 장애 조치(failover)가 발생하면 event_scheduler 서버 매개 변수가 'OFF'로 설정될 수 있습니다. 이러한 경우, 장애 조치(failover)가 완료되면 값이 'ON'으로 설정되도록 매개 변수를 구성합니다.
수정 불가능한 서버 매개 변수
Azure Portal의 서버 매개 변수 블레이드에는 수정 가능 여부에 상관 없이 서버 매개 변수가 모두 표시됩니다. 수정 불가능한 서버 매개 변수는 회색으로 표시됩니다. 세션 수준에서 수정 불가능한 서버 매개 변수를 구성하려는 경우 Azure Portal 또는 Azure CLI 문서에서 init_connect를 사용한 연결 수준에서의 매개 변수 설정을 참조하세요.
다음 단계
- Azure Portal에서 서버 매개 변수를 구성하는 방법
- Azure CLI에서 서버 매개 변수를 구성하는 방법