备用目录
/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)
默认值(字节)
最小值(字节)
最大值(字节)
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 - 灵活服务器最多支持 8 TB。 如果你的数据库大小超过 8 TB,应在
innodb_file_per_table
表空间中创建表。 如果单个表的大小超过 8 TB,应使用分区表。
innodb_log_file_size
innodb_log_file_size
的值表示
日志组
中每个
日志文件
的大小(以字节为单位)。 日志文件的合并大小
(innodb_log_file_size
*
innodb_log_files_in_group
) 不能超过最大值(最大值是一个略小于 512 GB 的值)。
日志文件大小越大,性能越好,但缺点是故障后的恢复时间会很长。 需要平衡极少发生的故障事件中的恢复时间与高峰操作期间最大吞吐量之间的关系。 更大的日志文件大小也会导致重启时间更长。
对于 Azure Database for MySQL - 灵活服务器,可以将
innodb_log_size
配置为 256 兆字节 (MB)、512 MB、1 GB 或 2 GB。 参数是静态的,需要重启。
如果更改了
innodb_log_file_size
参数的默认值,请检查值
show global status like 'innodb_buffer_pool_pages_dirty'
的值是否保持
0
30 秒,以避免重启延迟。
max_connections
服务器的内存大小确定
max_connections
的值。 下表中的
物理内存大小
表示 Azure Database for MySQL 灵活服务器上的可用 RAM,以千兆字节为单位。
vCore 数
物理内存大小 (GB)
当连接数超过限制时,可能会收到以下错误:“错误 1040 (08004):连接过多”。
创建客户端与 MySQL 的新连接需要一段时间。 建立这些连接后,即使它们处于空闲状态,它们也会占用数据库资源。 大多数应用程序会请求许多生存期短的连接,这加剧了这种情况。 其结果是可用于实际工作负荷的资源减少,从而导致性能下降。
连接池程序不仅会减少空闲连接,还会重用现有连接,因而有助于避免出现这个问题。 为了获得最佳体验,建议使用 ProxySQL 等连接池程序来高效地管理连接。 若要了解如何设置 ProxySQL,请参阅
这篇博客文章
。
ProxySQL 是一个开源社区工具。 Microsoft 尽最大努力提供支持。 若要获得权威指导的生产支持,请联系
ProxySQL 产品支持
。
innodb_strict_mode
如果收到类似于“行大小太大(> 8126)”的错误,则可能会想要关闭
innodb_strict_mode
服务器参数。 无法在服务器级别全局修改此参数,因为如果行数据大小大于 8K,则数据将被截断而不会出错。 这种截断可能会导致潜在的数据丢失。 建议修改架构以适应页面大小限制。
可以使用
init_connect
在会话级别设置此参数。 有关详细信息,请参阅
设置不可修改的服务器参数
。
如果有只读副本服务器,在源服务器上的会话级别将
innodb_strict_mode
设置为
OFF
会中断复制。 如果有只读副本,建议将该参数始终设置为
ON
。
time_zone
初始部署后,Azure Database for MySQL - 灵活服务器实例包含用于时区信息的系统表,但这些表中没有填充数据。 可以通过从 MySQL 命令行或 MySQL Workbench 等工具调用
mysql.az_load_timezone
存储过程来填充时区表。 还可以使用
Azure 门户
或
Azure CLI
调用存储过程并设置全局时区或会话级时区。
binlog_expire_logs_seconds
在 Azure Database for MySQL - 灵活服务器中,
binlog_expire_logs_seconds
参数指定在删除二进制日志文件之前该服务等待的秒数。
二进制日志包含描述数据库更改(例如表创建操作或对表数据所做的更改)的事件。 此二进制日志还包含可能已进行了更改的语句的事件。 二进制日志主要用于两个目的:复制和数据恢复操作。
通常,当句柄从服务、备份或副本集中释放后,二进制日志就会立即被删除。 如果有多个副本,二进制日志将等待速度最慢的副本读取更改,然后再将其删除。
如果希望二进制日志保留更长时间,则可以配置
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_scheduler
服务器参数管理创建、计划和运行事件。 也就是说,该参数管理由特殊 MySQL Event Scheduler 线程根据计划运行的任务。 当将
event_scheduler
参数设置为
ON
时,Event Scheduler 线程将在
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>'
<your statement>;
有关创建事件的详细信息,请参阅 MySQL 参考手册中有关 Event Scheduler 的以下文档:
在 MySQL 5.7 中使用 Event Scheduler
在 MySQL 8.0 中使用 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 门户中,前往 Azure Database for MySQL - 灵活服务器实例。 在“设置”下,选择“服务器参数”。
在“服务器参数”窗格中,搜索 event_scheduler
。 在“值”下拉列表中,选择“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'
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)
一小时后,对表运行 select
语句,查看每分钟插入表中的值的完整结果,持续一小时(因为在本例中 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@% |
| 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'
<your statement>;
若要每小时运行一次 SQL 语句,没有结束时间:
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
<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'
<your statement>;
对于配置了高可用性的服务器,发生故障转移时,event_scheduler
服务器参数可能会设置为 OFF
。 如果发生这种情况,故障转移完成后,请配置该参数以将值设置为 ON
。
不可修改的服务器参数
Azure 门户上的“服务器参数”窗格显示了可修改的服务器参数和不可修改的服务器参数。 不可修改的服务器参数将不可用。 可以在 Azure 门户或 Azure CLI 中使用 init_connect
在会话级别配置不可修改的服务器参数。
在 Azure 门户中配置服务器参数
在 Azure CLI 中配置服务器参数