Параметры сервера в Базе данных Azure для MySQL (Гибкий сервер)

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — гибкий сервер

В этой статье приведены рекомендации и рекомендации по настройке параметров сервера в База данных Azure для MySQL — гибкий сервер.

Что такое параметры сервера?

Подсистема MySQL предоставляет множество параметров сервера (также называемых переменными), которые можно использовать для настройки и настройки поведения ядра. Некоторые параметры можно задать динамически во время выполнения. Другие являются статическими и требуют перезапуска сервера после их установки.

В База данных Azure для MySQL — гибкий сервер можно изменить значение различных параметров сервера MySQL с помощью портал Azure и Azure CLI в соответствии с потребностями рабочей нагрузки.

Настраиваемые параметры сервера

Вы можете управлять конфигурацией База данных Azure для MySQL гибкого сервера с помощью параметров сервера. Параметры сервера настраиваются по умолчанию и рекомендуемыми значениями при создании сервера. В области параметров сервера в портал Azure отображаются изменяемые и неизменяемые параметры. Неизменяемые параметры сервера недоступны.

Список поддерживаемых параметров постоянно растет. Можно использовать портал Azure для периодического просмотра полного списка параметров сервера и настройки значений.

Если изменить параметр статического сервера с помощью портала, необходимо перезапустить сервер, чтобы изменения вступили в силу. Если вы используете сценарии автоматизации (с помощью таких средств, как шаблоны Azure Resource Manager, Terraform или Azure CLI), сценарий должен подготовиться для перезапуска службы, чтобы параметры вступили в силу, даже если вы изменяете конфигурацию в процессе создания.

Если вы хотите изменить немодифицируемый параметр сервера для вашей среды, опубликуйте идею с помощью отзывов сообщества или проголосуйте, если отзывы уже существуют (что может помочь нам определить приоритет).

В следующих разделах описываются ограничения часто обновляемых параметров сервера. Уровень вычислений и размер (виртуальные ядра) сервера определяют ограничения.

lower_case_table_names

Для MySQL версии 5.7 значение lower_case_table_names по умолчанию находится 1 в База данных Azure для MySQL — гибкий сервер. Несмотря на то что можно изменить поддерживаемое значение 2на , отмена обратно 2 на 1 не допускается. Чтобы помочь в изменении значения по умолчанию, создайте запрос в службу поддержки.

Для MySQL версии 8.0+ можно настроить lower_case_table_names только при инициализации сервера. Подробнее. lower_case_table_names Изменение параметра после инициализации сервера запрещено.

Поддерживаемые значения для MySQL версии 8.0 находятся 1 в 2 База данных Azure для MySQL — гибкий сервер. Значение по умолчанию — 1. Чтобы помочь в изменении значения по умолчанию во время создания сервера, создайте запрос в службу поддержки.

innodb_tmpdir

Параметр innodb_tmpdir в База данных Azure для MySQL — гибкий сервер используется для определения каталога для временных файлов сортировки, созданных во время перестроения в сетиALTER TABLE.

Значение innodb_tmpdir по умолчанию — /mnt/temp. Это расположение соответствует временному хранилищу (SSD) и доступно в гибибайтах (GiB) с каждым размером вычислительных ресурсов сервера. Это расположение идеально подходит для операций, для которых не требуется большое количество места.

Если требуется больше места, можно задать значение innodb_tmpdir /app/work/tmpdir. Этот параметр использует доступную емкость хранилища на База данных Azure для 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 для MySQL — гибкий сервер, двоичные журналы всегда включены (то есть log_bin задано значение ON). Параметр log_bin_trust_function_creators по умолчанию устанавливается ON на гибких серверах.

Формат двоичного ведения журнала всегда ROWдоступен, а подключения к серверу всегда используют двоичное ведение журнала на основе строк. При использовании двоичного ведения журнала на основе строк проблемы безопасности не существуют, и двоичное ведение журнала не может прерываться, поэтому вы можете безопасно разрешить log_bin_trust_function_creators оставаться как ON.

Если log_bin_trust_function_creators задано OFF значение, и вы пытаетесь создать триггеры, могут возникнуть ошибки, аналогичные: "У вас нет привилегий SUPER, а двоичное ведение журнала включено (может потребоваться использовать менее безопасную log_bin_trust_function_creators переменную)."

innodb_buffer_pool_size

Чтобы узнать о параметре innodb_buffer_pool_size , ознакомьтесь с документацией по MySQL.

Размер физической памяти в следующей таблице представляет доступную память случайного доступа (ОЗУ) в гигабайтах (ГБ) на гибком сервере База данных Azure для MySQL.

innodb_file_per_table

MySQL сохраняет таблицу InnoDB в разных пространствах таблиц на основе конфигурации, предоставленной во время создания таблицы. Табличное пространство системы — это область хранения для словаря данных InnoDB. Пространство таблиц для каждого файла содержит данные и индексы для одной таблицы InnoDB, и она хранится в файловой системе в собственном файле данных. Параметр сервера innodb_file_per_table управляет этим поведением.

Если задать для innodb_file_per_table значение OFF, InnoDB создаст таблицы в системном табличном пространстве. В противном случае InnoDB создает таблицы в табличных пространствах file-per-table.

База данных Azure для MySQL — гибкий сервер поддерживает не более 8 терабайт (ТБ) в одном файле данных. Если размер базы данных превышает 8 ТБ, необходимо создать таблицу innodb_file_per_table в пространстве таблиц. Если размер одной таблицы превышает 8 ТБ, следует использовать таблицу секционирования.

innodb_log_file_size

Значением innodb_log_file_size является размер (в байтах) каждого файла журнала в группе журналов. Объединенный размер файлов журнала (innodb_log_file_size innodb_log_files_in_group * ) не может превышать максимальное значение, которое чуть меньше 512 ГБ.

Больший размер файла журнала лучше подходит для производительности, но недостаток заключается в том, что время восстановления после сбоя является высоким. Необходимо сбалансировать время восстановления для редкого события сбоя и максимизации пропускной способности во время пиковых операций. Более большой размер файла журнала также может привести к более длительному времени перезапуска.

Можно настроить innodb_log_size 256 мегабайт (МБ), 512 МБ, 1 ГБ или 2 ГБ для База данных Azure для MySQL — гибкий сервер. Параметр является статическим и требует перезагрузки.

max_connections

Размер памяти сервера определяет значение max_connections. Размер физической памяти в следующей таблице представляет доступную ОЗУ в гигабайтах на База данных Azure для MySQL гибком сервере.

Если подключения превышают предел, может появиться следующая ошибка: ERROR 1040 (08004): слишком много подключений.

Создание новых клиентских подключений к MySQL занимает время. После установки этих подключений они занимают ресурсы базы данных, даже если они неактивные. Большинство приложений запрашивают много кратковременных соединений, из-за которых и возникает такая ситуация. Результатом является меньше ресурсов, доступных для вашей фактической рабочей нагрузки, что приводит к снижению производительности.

Пул подключений, который уменьшает простои подключений и повторно использует существующие подключения, помогает избежать этой проблемы. Для лучшего взаимодействия рекомендуется использовать пул подключений, например ProxySQL, для эффективного управления подключениями. Дополнительные сведения о настройке ProxySQL см . в этой записи блога.

innodb_strict_mode

Если вы получаете ошибку, аналогичную ошибке "Размер строки слишком большой (> 8126)," может потребоваться отключить innodb_strict_mode параметр сервера. Этот параметр нельзя изменить глобально на уровне сервера, так как если размер данных строки превышает 8 КБ, данные усечены без ошибки. Это усечение может привести к потенциальной потере данных. Рекомендуется изменить схему в соответствии с предельным размером страницы.

Этот параметр можно задать на уровне сеанса с помощью init_connect. Дополнительные сведения см. в разделе "Настройка неизменяемых параметров сервера".

time_zone

При первоначальном развертывании База данных Azure для MySQL — гибкий экземпляр сервера включает системные таблицы для сведений часового пояса, но эти таблицы не заполняются. Таблицы часовых поясов можно заполнить, вызвав mysql.az_load_timezone хранимую процедуру из средства, например командной строки MySQL или MySQL Workbench. Вы также можете вызвать хранимую процедуру и задать глобальные или часовые пояса уровня сеанса с помощью портал Azure или Azure CLI.

binlog_expire_logs_seconds

В База данных Azure для MySQL — гибкий сервер binlog_expire_logs_seconds параметр указывает количество секунд, которое служба ожидает перед удалением двоичного файла журнала.

Двоичный журнал содержит события с описанием изменений в базе данных, таких как операции создания таблицы или изменения данных таблицы. Двоичный журнал также содержит события для инструкций, которые потенциально могли бы вносить изменения. Двоичный журнал используется главным образом для двух целей: репликации и операций восстановления данных.

Как правило, двоичные журналы удаляются, как только дескриптор свободен от службы, резервного копирования или набора реплик. Если существует несколько реплик, двоичные журналы ожидают, пока самая медленная реплика будет считывать изменения до их удаления.

Если вы хотите сохранить двоичные журналы в течение длительного времени, можно настроить binlog_expire_logs_seconds параметр. Если binlog_expire_logs_seconds задано значение 0по умолчанию, двоичный журнал удаляется сразу после освобождения дескриптора. Если значение binlog_expire_logs_seconds больше 0, двоичный журнал удаляется после заданного количества секунд.

База данных Azure для MySQL — гибкий сервер обрабатывает управляемые функции, такие как резервное копирование и удаление реплики чтения двоичных файлов, внутренне. При репликации данных из База данных Azure для MySQL — гибкий сервер этот параметр необходимо задать в основном, чтобы избежать удаления двоичных журналов, прежде чем реплика считывает изменения в основном сервере. Если задано binlog_expire_logs_seconds более высокое значение, двоичные журналы не будут удалены в ближайшее время. Эта задержка может привести к увеличению выставления счетов за хранение.

event_scheduler

В База данных Azure для MySQL — гибкий сервер, event_scheduler параметр сервера управляет созданием, планированием и выполнением событий. То есть параметр управляет задачами, выполняемыми в соответствии с расписанием специальным потоком планировщика событий MySQL. 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:

• Использование планировщика событий в MySQL 5.7
• Использование планировщика событий в MySQL 8.0

Настройка параметра сервера event_scheduler

В следующем сценарии показан один из способов использования event_scheduler параметра в База данных Azure для MySQL — гибкий сервер.

Чтобы продемонстрировать сценарий, рассмотрим следующий пример простой таблицы:

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 для MySQL — гибкий event_scheduler сервер, выполните следующие действия:

1. В портал Azure перейдите к экземпляру гибкого сервера База данных Azure для MySQL. В разделе Параметры выберите Параметры сервера.

2. На панели параметров сервера найдите event_scheduler. В раскрывающемся списке VALUE выберите ON и нажмите кнопку "Сохранить".

   Примечание.

   Развертывание динамической конфигурации для параметра сервера не требует перезагрузки.

3. Чтобы создать событие, подключитесь к экземпляру гибкого сервера База данных Azure для 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());
   

4. Чтобы просмотреть сведения о планировщике событий, выполните следующую инструкцию 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)
   

5. Через несколько минут запросите строки из таблицы, чтобы начать просмотр строк, вставляемых каждую минуту в соответствии с настроенным параметром 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)
   

6. Через час выполните 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'
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>;

Ограничения

Для серверов с высокой доступностью, настроенных при отработки отказа, возможно event_scheduler , что для параметра сервера задано значение OFF. Если это происходит, когда отработка отказа завершена, настройте параметр, чтобы задать значение ON.

Параметры сервера, не изменяемые

В области параметров сервера в портал Azure отображаются изменяемые и неизменяемые параметры сервера. Неизменяемые параметры сервера недоступны. Параметр сервера без изменения можно настроить на уровне сеанса с помощью init_connect портал Azure или Azure CLI.

Связанный контент

• Настройка параметров сервера в портал Azure
• Настройка параметров сервера в Azure CLI