이 문서에서는 Azure Database for MySQL - 유연한 서버에서 서버 매개 변수를 구성하는 데 있어서의 고려 사항 및 지침을 제공합니다.
참고
이 문서에는 Microsoft에서 더 이상 사용하지 않는 용어인 slave에 대한 참조가 포함되어 있습니다. 소프트웨어에서 용어가 제거되면 이 문서에서 해당 용어가 제거됩니다.
서버 매개 변수는 무엇인가요?
MySQL 엔진은 엔진 동작을 구성하고 조정하는 데 사용할 수 있는 많은 서버 매개 변수(변수)를 제공합니다. 일부 매개 변수는 런타임 중에 동적으로 설정할 수 있습니다. 일부 설정은 정적이며, 설정한 후 서버를 다시 시작해야 합니다.
Azure Database for MySQL - 유연한 서버에서는 Azure Portal을 사용하여 Azure Database for MySQL - 유연한 서버의 서버 매개 변수 구성 및 Azure CLI를 사용하여 Azure Database for MySQL - 유연한 서버의 서버 매개 변수 구성을 통해 다양한 MySQL 서버 매개 변수의 값을 변경하여 워크로드 요구 사항에 맞게 조정할 수 있습니다.
구성 가능한 서버 매개 변수
서버 매개 변수를 사용하여 Azure Database for MySQL 유연한 서버 구성을 관리할 수 있습니다. 서버 매개 변수는 서버를 만들 때 기본/권장 값으로 구성됩니다. Azure Portal의 서버 매개 변수 창에는 수정 가능/불가능한 매개 변수가 모두 표시됩니다. 수정 불가능한 서버 매개 변수는 사용할 수 없습니다.
지원되는 서버 매개 변수 목록은 계속 확장됩니다. Azure Portal을 사용하면 서버 매개 변수의 전체 목록을 주기적으로 확인하고 값을 구성할 수 있습니다.
포털을 사용하여 정적 서버 매개 변수를 수정하는 경우 변경 내용을 적용하려면 서버를 다시 시작해야 합니다. Azure Resource Manager 템플릿, Terraform 또는 Azure CLI와 같은 도구를 통해 자동화 스크립트를 사용하는 경우, 만들기 환경의 일부로 구성을 변경하는 경우에도 설정이 적용되도록 서비스를 다시 시작할 수 있는 프로비전이 스크립트에 있어야 합니다.
사용 중인 환경에서 수정할 수 없는 서버 매개 변수를 수정하려면 커뮤니티 피드백을 통해 아이디어를 게시하거나, 이미 해당 피드백이 있는 경우에는 투표를 통해 Microsoft에서 우선 순위 지정에 도움이 되도록 합니다.
다음 섹션에서는 일반적으로 업데이트되는 서버 매개 변수의 제한에 대해 설명합니다. 컴퓨팅 계층과 서버의 크기(vCore)에 따라 제한이 결정됩니다.
lower_case_table_names
MySQL 버전 5.7의 경우, Azure Database for MySQL 유연한 서버에서 lower_case_table_names
의 기본값은 1
입니다. 지원되는 값을 2
로 변경할 수는 있지만 2
에서 1
로 되돌리는 것은 허용되지 않습니다. 기본값 변경에 대한 지원을 받으려면 에서 지원 티켓 를 만드세요.
MySQL 버전 8.0 이상에서는 서버를 초기화할 때만 lower_case_table_names
를 구성할 수 있습니다. 자세히 알아보세요. 서버를 초기화한 후에는 lower_case_table_names
설정을 변경하는 것이 금지됩니다.
MySQL 버전 8.0에서는 Azure Database for MySQL - 유연한 서버 값으로 1
및 2
를 지원합니다. 기본값은 1
입니다. 서버 생성 중에 기본값을 변경하는 데 도움이 필요하면 지원 티켓을 만드세요.
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
에 대해 제공된 정보는 innodb_temp_tablespaces_dir, tmpdir, slave_load_tmpdir 매개 변수에 적용할 수 있습니다.
- 일반적인 기본값은
/mnt/temp
입니다. - 대체 디렉터리인
/app/work/tmpdir
은 특정 운영 요구 사항에 따라 성능에 따른 균형을 유지하면서 임시 스토리지를 늘리는 데 사용할 수 있습니다.
log_bin_trust_function_creators
Azure Database for MySQL - 유연한 서버에서 이진 로그는 항상 사용 설정됩니다(log_bin
이 ON
으로 설정됨). log_bin_trust_function_creators
매개 변수는 유연한 서버에서 기본적으로 ON
으로 설정됩니다.
이진 로깅 형식은 항상 ROW
이고, 서버에 대한 모든 연결은 항상 행 기반 이진 로깅을 사용합니다. 행 기반 이진 로깅을 사용하면 보안 문제가 없고 이진 로깅이 중단되지 않으므로 log_bin_trust_function_creators
를 안전하게 ON
으로 유지해 둘 수 있습니다.
log_bin_trust_function_creators
가 OFF
로 설정된 경우, 트리거를 만들려고 하면 "슈퍼 권한이 없고 이진 로깅이 사용 설정되었습니다(덜 안전한 log_bin_trust_function_creators
변수를 사용하는 것이 좋습니다)"와 유사한 오류가 발생할 수 있습니다.
innodb_buffer_pool_size
innodb_buffer_pool_size
매개 변수에 대해 자세히 알아보려면 MySQL 설명서를 검토하세요.
다음 표의 실제 메모리 크기는 Azure Database for MySQL 유연한 서버에서 사용 가능한 RAM(임의 액세스 메모리)(GB, 기가바이트)을 나타냅니다.
컴퓨팅 크기 | vCore 수 | 실제 메모리 크기(GB) | 기본값(바이트) | 최솟값(바이트) | 최댓값(바이트) |
---|---|---|---|---|---|
버스트 가능 | |||||
Standard_B1s | 1 | 1 | 134217728 | 33554432 | 268435456 |
Standard_B1ms | 1 | 2 | 536870912 | 134217728 | 1073741824 |
Standard_B2s | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
Standard_B2ms | 2 | 8 (여덟) | 4294967296 | 134217728 | 5368709120 |
Standard_B4ms | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
Standard_B8ms | 8 (여덟) | 32 | 25769803776 | 134217728 | 25769803776 |
Standard_B12ms | 12 | 48 | 51539607552 | 134217728 | 32212254720 |
Standard_B16ms | 16 | 64 | 2147483648 | 134217728 | 51539607552 |
Standard_B20ms | 20 | 80 | 64424509440 | 134217728 | 64424509440 |
범용 | |||||
Standard_D2ads_v5 | 2 | 8 (여덟) | 4294967296 | 134217728 | 5368709120 |
Standard_D2ds_v4 | 2 | 8 (여덟) | 4294967296 | 134217728 | 5368709120 |
Standard_D4ads_v5 | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
Standard_D4ds_v4 | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
Standard_D8ads_v5 | 8 (여덟) | 32 | 25769803776 | 134217728 | 25769803776 |
Standard_D8ds_v4 | 8 (여덟) | 32 | 25769803776 | 134217728 | 25769803776 |
Standard_D16ads_v5 | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
Standard_D16ds_v4 | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
Standard_D32ads_v5 | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
Standard_D32ds_v4 | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
Standard_D48ads_v5 | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
Standard_D48ds_v4 | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
Standard_D64ads_v5 | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
Standard_D64ds_v4 | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
중요 비즈니스 | |||||
Standard_E2ds_v4 | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
Standard_E2ads_v5, Standard_E2ds_v5 | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
Standard_E4ds_v4 | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
Standard_E4ads_v5, Standard_E4ds_v5 | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
Standard_E8ds_v4 | 8 (여덟) | 64 | 51539607552 | 134217728 | 51539607552 |
Standard_E8ads_v5, Standard_E8ds_v5 | 8 (여덟) | 64 | 51539607552 | 134217728 | 51539607552 |
Standard_E16ds_v4 | 16 | 128 | 103,079,215,104 | 134217728 | 103079215104 |
Standard_E16ads_v5, Standard_E16ds_v5 | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
Standard_E20ds_v4 | 20 | 160 | 128849018880 | 134217728 | 128849018880 |
Standard_E20ads_v5, Standard_E20ds_v5 | 20 | 160 | 128849018880 | 134217728 | 128849018880 |
Standard_E32ds_v4 | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
Standard_E32ads_v5, Standard_E32ds_v5 | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
Standard_E48ds_v4 | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
Standard_E48ads_v5, Standard_E48ds_v5 | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
Standard_E64ds_v4 | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
Standard_E64ads_v5 , Standard_E64ds_v5 | 64 | 512 | 412316860416 | 134217728 | 412316860416 |
Standard_E80ids_v4 | 80 | 504 | 405874409472 | 134217728 | 405874409472 |
Standard_E96ds_v5 | 96 | 672 | 541165879296 | 134217728 | 541165879296 |
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 - 유연한 서버는 단일 데이터 파일에서 최대 8TB(테라바이트)를 지원합니다. 데이터베이스 크기가 8TB보다 큰 경우 innodb_file_per_table
테이블스페이스에 테이블을 만들어야 합니다. 단일 테이블 크기가 8TB보다 큰 경우에는 파티션 테이블을 사용해야 합니다.
innodb_log_file_size
innodb_log_file_size의 값은 로그 그룹에 있는 각 로그 파일의 크기(바이트)입니다. 결합된 로그 파일(innodb_log_file_size * innodb_log_files_in_group)의 크기는 512GB보다 약간 작은 최댓값을 초과할 수 없습니다.
로그 파일 크기가 더 크면 성능에는 더 좋지만, 충돌 후 복구 시간이 길어진다는 단점이 있습니다. 드물게 충돌이 발생하는 경우 복구 시간과 최대 작업 중 처리량 최대화의 균형을 유지해야 합니다. 로그 파일 크기가 클수록 다시 시작하는 시간이 길어질 수도 있습니다.
Azure Database for MySQL - 유연한 서버에 대해 256MB(메가바이트), 512MB, 1GB, 2GB로 innodb_log_size
를 구성할 수 있습니다. 매개 변수가 정적이며 다시 시작해야 합니다.
참고
기본값에서 innodb_log_file_size
매개 변수를 변경한 경우, 다시 시작 지연을 방지하기 위해 show global status like 'innodb_buffer_pool_pages_dirty'
의 값이 30초 동안 0
으로 유지되는지 확인하세요.
최대 연결 수
서버의 메모리 크기에 따라 max_connections
값이 결정됩니다. 다음 테이블의 실제 메모리 크기는 Azure Database for MySQL 유연한 서버에서 사용 가능한 RAM을 기가바이트블 단위로 나타냅니다.
컴퓨팅 크기 | vCore 수 | 실제 메모리 크기(GB) | 기본값 | 최솟값 | 최댓값 |
---|---|---|---|---|---|
버스트 가능 | |||||
Standard_B1s | 1 | 1 | 85 | 10 | 171 |
Standard_B1ms | 1 | 2 | 171 | 10 | 341 |
Standard_B2s | 2 | 4 | 341 | 10 | 683 |
Standard_B2ms | 2 | 4 | 683 | 10 | 1365 |
Standard_B4ms | 4 | 16 | 1365 | 10 | 2731 |
Standard_B8ms | 8 (여덟) | 32 | 2731 | 10 | 5461 |
Standard_B12ms | 12 | 48 | 4097 | 10 | 8193 |
Standard_B16ms | 16 | 64 | 5461 | 10 | 10923 |
Standard_B20ms | 20 | 80 | 6827 | 10 | 13653 |
범용 | |||||
Standard_D2ads_v5 | 2 | 8 (여덟) | 683 | 10 | 1365 |
Standard_D2ds_v4 | 2 | 8 (여덟) | 683 | 10 | 1365 |
Standard_D4ads_v5 | 4 | 16 | 1365 | 10 | 2731 |
Standard_D4ds_v4 | 4 | 16 | 1365 | 10 | 2731 |
Standard_D8ads_v5 | 8 (여덟) | 32 | 2731 | 10 | 5461 |
Standard_D8ds_v4 | 8 (여덟) | 32 | 2731 | 10 | 5461 |
Standard_D16ads_v5 | 16 | 64 | 5461 | 10 | 10923 |
Standard_D16ds_v4 | 16 | 64 | 5461 | 10 | 10923 |
Standard_D32ads_v5 | 32 | 128 | 10923 | 10 | 21845 |
Standard_D32ds_v4 | 32 | 128 | 10923 | 10 | 21845 |
Standard_D48ads_v5 | 48 | 192 | 16384 | 10 | 32768 |
Standard_D48ds_v4 | 48 | 192 | 16384 | 10 | 32768 |
Standard_D64ads_v5 | 64 | 256 | 21845 | 10 | 43691 |
Standard_D64ds_v4 | 64 | 256 | 21845 | 10 | 43691 |
중요 비즈니스 | |||||
Standard_E2ds_v4 | 2 | 16 | 1365 | 10 | 2731 |
Standard_E2ads_v5, Standard_E2ds_v5 | 2 | 16 | 1365 | 10 | 2731 |
Standard_E4ds_v4 | 4 | 32 | 2731 | 10 | 5461 |
Standard_E4ads_v5, Standard_E4ds_v5 | 4 | 32 | 2731 | 10 | 5461 |
Standard_E8ds_v4 | 8 (여덟) | 64 | 5461 | 10 | 10923 |
Standard_E8ads_v5, Standard_E8ds_v5 | 8 (여덟) | 64 | 5461 | 10 | 10923 |
Standard_E16ds_v4 | 16 | 128 | 10923 | 10 | 21845 |
Standard_E16ads_v5, Standard_E16ds_v5 | 16 | 128 | 10923 | 10 | 21845 |
Standard_E20ds_v4 | 20 | 160 | 13653 | 10 | 27306 |
Standard_E20ads_v5, Standard_E20ds_v5 | 20 | 160 | 13653 | 10 | 27306 |
Standard_E32ds_v4 | 32 | 256 | 21845 | 10 | 43691 |
Standard_E32ads_v5, Standard_E32ds_v5 | 32 | 256 | 21845 | 10 | 43691 |
Standard_E48ds_v4 | 48 | 384 | 32768 | 10 | 65536 |
Standard_E48ads_v5, Standard_E48ds_v5 | 48 | 384 | 32768 | 10 | 65536 |
Standard_E64ds_v4 | 64 | 504 | 43008 | 10 | 86016 |
Standard_E64ads_v5, Standard_E64ds_v5 | 64 | 512 | 43691 | 10 | 87383 |
Standard_E80ids_v4 | 80 | 504 | 43008 | 10 | 86016 |
Standard_E96ds_v5 | 96 | 672 | 50000 | 10 | 100000 |
연결 수가 제한을 초과하면 다음 오류가 나타날 수 있습니다. "오류 1040(08004): 연결이 너무 많습니다."
MySQL에 대한 새 클라이언트 연결을 만드는 데는 시간이 걸립니다. 이러한 연결을 설정한 후에는 유휴 상태인 경우에도 데이터베이스 리소스를 차지합니다. 대부분의 애플리케이션은 많은 단기 연결을 요청합니다. 이는 이러한 상황을 복잡하게 만듭니다. 결과적으로 실제 워크로드에 사용할 수 있는 리소스의 성능이 저하됩니다.
유휴 상태의 연결을 줄이고 기존 연결을 다시 사용하는 연결 풀러는 이러한 문제를 방지하는 데 도움이 됩니다. 최상의 환경을 위해 ProxySQL과 같은 연결 풀러를 사용하여 연결을 효율적으로 관리하는 것이 좋습니다. ProxySQL 설정에 대해 알아보려면 이 블로그 게시물을 참조하세요.
참고
ProxySQL은 오픈 소스 커뮤니티 도구입니다. Microsoft는 최선을 다해 지원합니다. 신뢰할 수 있는 지침으로 프로덕션 지원을 받으려면 ProxySQL 제품 지원에 문의하세요.
innodb_strict_mode
"행 크기가 너무 큼(> 8126)"과 유사한 오류가 표시되는 경우 innodb_strict_mode
서버 매개 변수를 해제할 수 있습니다. 행 데이터 크기가 8K보다 크면 데이터가 오류 없이 잘리므로 이 매개 변수는 서버 수준에서 전역적으로 수정할 수 없습니다. 이러한 잘림으로 인해 잠재적인 데이터 손실이 발생할 수 있습니다. 페이지 크기 제한에 맞춰 스키마를 수정하는 것이 좋습니다.
init_connect
를 사용하여 세션 수준에서 이 매개 변수를 설정할 수 있습니다. 자세한 내용은 수정할 수 없는 서버 매개 변수 설정을 참조하세요.
참고
읽기 복제본 서버가 있는 경우 원본 서버에서 세션 수준으로 innodb_strict_mode
를 OFF
로 설정하면 복제가 중단됩니다. 읽기 복제본이 있는 경우 매개 변수를 ON
으로 유지하는 것이 좋습니다.
시간대
초기 배포 시 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
가 설정된 경우, 이진 로그는 핸들이 해제되는 즉시 삭제됩니다. binlog_expire_logs_seconds
값이 0
보다 크면 구성된 시간(초)이 지난 후에 이진 로그가 삭제됩니다.
Azure Database for MySQL - 유연한 서버는 이진 파일의 백업 및 읽기 복제본 삭제 등 관리되는 기능을 내부적으로 처리합니다. Azure Database for MySQL - 유연한 서버에서 데이터 출력을 복제할 때 복제본이 기본 데이터베이스의 변경 내용을 읽기 전에 이진 로그가 삭제되는 것을 방지하기 위해 기본 데이터베이스에서 이 매개 변수를 설정해야 합니다. binlog_expire_logs_seconds
를 더 높은 값으로 설정하면 이진 로그가 바로 삭제되지 않습니다. 이러한 지연으로 인해 스토리지 청구 금액이 증가할 수 있습니다.
이벤트 스케줄러
Azure Database for MySQL - 유연한 서버에서 event_scheduler
서버 매개 변수는 이벤트 만들기, 일정 예약, 실행 등을 관리합니다. 즉, 매개 변수는 특수한 MySQL Event Scheduler 스레드의 일정에 따라 실행되는 작업을 관리합니다. event_scheduler
매개 변수가 ON
으로 설정되면 Event Scheduler 스레드가 SHOW PROCESSLIST
출력에 디먼 프로세스로 나열됩니다.
MySQL 버전 5.7 서버의 경우, 백업이 시작되면 서버 매개 변수 event_scheduler
라 자동으로 'OFF'로 전환되고, 백업이 성공적으로 완료되면 서버 매개 변수 event_scheduler
가 다시 'ON'으로 전환됩니다. Azure Database for MySQL - 유연한 서버용 MySQL 버전 8.0에서는 event_scheduler가 백업 중에 영향을 받지 않습니다. 보다 원활한 운영을 보장하려면 주 버전 업그레이드를 사용하여 MySQL 5.7 서버를 버전 8.0으로 업그레이드하는 것이 좋습니다.
다음 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) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |
1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.
> [!NOTE]
> Deployment of the dynamic configuration change to the server parameter doesn't require a restart.
1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
```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());
```
1. To view the Event Scheduler details, run the following SQL statement:
```sql
SHOW EVENTS;
```
The following output appears:
```sql
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) |
| ``` |
1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:
```azurecli
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) |
| ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
```azurecli
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) |
| ``` |
#### Other scenarios
You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.
To run a SQL statement now and repeat one time per day with no end:
```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
으로 설정되도록 매개 변수를 구성합니다.
innodb_ft_user_stopword_table
innodb_ft_user_stopword_table
는 InnoDB 전체 텍스트 검색을 위한 사용자 지정 중지 단어가 포함된 테이블의 이름을 지정하는 MySQL의 서버 매개 변수입니다. 테이블은 전체 텍스트 인덱스 테이블과 동일한 데이터베이스에 있어야 하며, 첫 번째 열은 VARCHAR
형식이어야 합니다. Azure Database for MySQL - 유연한 서버에서 sql_generate_invisible_primary_key=ON
의 기본 설정은 명시적 기본 키가 없는 모든 테이블이 보이지 않는 기본 키를 자동으로 포함하도록 합니다. 이 동작은 innodb_ft_user_stopword_table
에 대한 요구 사항과 충돌합니다. 보이지 않는 기본 키가 테이블의 첫 번째 열이 되므로 전체 텍스트 검색 중에 의도한 대로 작동하지 않기 때문입니다. 이 문제를 해결하려면 사용자 지정 중지 단어 테이블을 만들기 전에 동일한 세션에서 sql_generate_invisible_primary_key=OFF
를 설정해야 합니다. 예:
SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');
이렇게 하면 중지 단어 테이블이 MySQL의 요구 사항을 충족하고 사용자 지정 중지 단어가 제대로 작동할 수 있습니다.
수정 불가능한 서버 매개 변수
Azure Portal의 서버 매개 변수 창에는 수정 가능/불가능한 서버 매개 변수가 모두 표시됩니다. 수정 불가능한 서버 매개 변수는 사용할 수 없습니다. Azure portal 또는 Azure CLI에서 init_connect
를 사용하여 세션 수준에서 수정할 수 없는 서버 매개 변수를 구성할 수 있습니다.
Azure mysql 시스템 변수
azure_server_name (애저 서버 이름)
변수는 azure_server_name
Azure Database for MySQL - 유연한 서버 인스턴스의 정확한 서버 이름을 제공합니다. 이 변수는 애플리케이션 또는 스크립트가 외부 구성에 의존하지 않고 연결된 서버의 호스트 이름을 프로그래밍 방식으로 검색해야 하며 MySQL 내에서 다음 명령을 실행하여 검색할 수 있는 경우에 유용합니다.
mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name | Value |
+-------------------+---------+
| azure_server_name | myflex |
+-------------------+---------+
참고: azure_server_name
HA 사용 및 HA 사용 안 함 서버 모두에 대해 서비스에 연결하는 데 사용하는 원래 서버 이름(예: myflex)을 일관되게 반환합니다.
논리적_서버_이름
변수는 logical_server_name
Azure Database for MySQL - 유연한 서버가 실행 중인 인스턴스의 호스트 이름을 나타냅니다. 이 변수는 서비스가 현재 실행 중인 호스트를 식별하여 문제 해결 및 장애 조치(failover) 모니터링을 지원하는 데 유용합니다. MySQL 내에서 다음 명령을 실행하여 이 변수를 검색할 수 있습니다.
mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name | Value |
+---------------------+--------------+
| logical_server_name | myflex |
+---------------------+--------------+
참고: HA 사용 서버의 경우 변수는 logical_server_name
주 서버 역할을 하는 인스턴스의 호스트 이름을 반영합니다. HA를 사용하지 않도록 설정된 서버의 logical_server_name
경우 값은 단일 인스턴스만 있으므로 변수와 azure_server_name
동일합니다.