Поделиться через

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

  • Статья

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

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

Примечание.

Эта статья содержит упоминания термина slave (ведомый) . Корпорация Майкрософт больше не использует его. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.

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

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

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

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

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

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

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

Примечание.

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

lower_case_table_names

Для MySQL версии 5.7 значение по умолчанию равно 1 в База данных Azure для MySQL гибком сервере. Важно отметить, что в то время как можно изменить поддерживаемое значение на 2, отмена от 2 обратно до 1 не допускается. Обратитесь в нашу службу поддержки, чтобы помочь в изменении значения по умолчанию. Для MySQL версии 8.0+ lower_case_table_names можно настроить только при инициализации сервера. Подробнее. Изменение параметра lower_case_table_names после инициализации сервера запрещено. Для MySQL версии 8.0 значение по умолчанию равно 1 в База данных Azure для MySQL гибком сервере. Поддерживаемое значение для MySQL версии 8.0: 1 и 2 на гибком сервере База данных Azure для MySQL. Обратитесь в нашу службу поддержки, чтобы помочь в изменении значения по умолчанию во время создания сервера.

innodb_tmpdir

Параметр innodb_tmpdir в База данных Azure для MySQL Гибкий сервер используется для определения каталога для временных файлов сортировки, созданных во время операций alter TABLE в сети, которые перестроены. Значение по умолчанию innodb_tmpdir /mnt/temp. Это расположение соответствует временному SSD-хранилищу, доступному в ГиБ с каждым размером вычислительных ресурсов сервера. Это расположение идеально подходит для операций, для которых не требуется большое количество места. Если требуется больше места, можно задать для 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 по умолчанию включен.

В качестве формата двоичного журнала всегда выбран вариант ROW, а для всех подключений к серверу двоичные журналы ВСЕГДА ведутся на основе строк. При использовании двоичного ведения журнала на основе строк проблемы безопасности не существуют, и двоичное ведение журнала не может прерываться, поэтому вы можете безопасно разрешить log_bin_trust_function_creators оставаться включено.

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

innodb_buffer_pool_size

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

Ценовая категория Виртуальные ядра Размер физической памяти (ГиБ) Значение по умолчанию (байт) Минимальное значение (байт) Максимальное значение (байт)
С увеличивающейся производительностью (B1s) 1 1 134217728 33554432 268435456
С увеличивающейся производительностью (B1ms) 1 2 536 870 912 134217728 1073741824
Ускорение (B2s) 2 4 2147483648 134217728 2147483648
Ускорение (B2ms) 2 8 4294967296 134217728 5368709120
С увеличивающейся производительностью 4 16 12884901888 134217728 12884901888
С увеличивающейся производительностью 8 32 25769803776 134217728 25769803776
С увеличивающейся производительностью 12 48 51539607552 134217728 51539607552
С увеличивающейся производительностью 16 64 2147483648 134217728 2147483648
С увеличивающейся производительностью 20 80 64424509440 134217728 64424509440
Общего назначения 2 8 4294967296 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
Критически важный для бизнеса 20 160 128849018880 134217728 128849018880
Критически важный для бизнеса 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 для 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. Параметр является статическим и требует перезагрузки.

Примечание.

Если вы изменили параметр innodb_log_file_size по умолчанию, убедитесь, что значение "показывать глобальное состояние, например innodb_buffer_pool_pages_dirty" остается равным 0 в течение 30 секунд, чтобы избежать задержки перезапуска.

max_connections

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

Ценовая категория Виртуальные ядра Размер физической памяти (ГиБ) Значение по умолчанию Минимальное значение Максимальное значение
С увеличивающейся производительностью (B1s) 1 1 85 10 171
С увеличивающейся производительностью (B1ms) 1 2 171 10 341
Ускорение (B2s) 2 4 341 10 683
Ускорение (B2ms) 2 4 683 10 1365
С увеличивающейся производительностью 4 16 1365 10 2731
С увеличивающейся производительностью 8 32 2731 10 5461
С увеличивающейся производительностью 12 48 4097 10 8193
С увеличивающейся производительностью 16 64 5461 10 10923
С увеличивающейся производительностью 20 80 6827 10 13653
Общего назначения 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
Критически важный для бизнеса 20 160 13653 10 27306
Критически важный для бизнеса 32 256 21845 10 43691
Критически важный для бизнеса 48 384 32768 10 65536
Критически важный для бизнеса 64 504 43008 10 86016

При превышении предельного количества подключений может появиться следующая ошибка:

ОШИБКА 1040 (08004): Слишком много подключений

Внимание

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

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

Примечание.

ProxySQL — это продукт сообщества разработчиков решений с открытым кодом. Это решение по мере возможности поддерживается корпорацией Майкрософт. Чтобы получить помощь и полезные инструкции для своей рабочей среды, вы можете обратиться в службу поддержки продуктов ProxySQL.

innodb_strict_mode

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

Этот параметр можно задать на уровне сеанса с помощью init_connect. Сведения о том, как задать innodb_strict_mode на уровне сеанса, см. в разделе об отсутствии в списке параметра настройки.

Примечание.

При наличии сервера-реплики чтения отключение параметра innodb_strict_mode на уровне сеанса на исходном сервере приведет к нарушению репликации. При наличии реплик чтения рекомендуем оставить параметр включенным.

time_zone

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

binlog_expire_logs_seconds

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

Двоичный журнал содержит "события", описывающие изменения базы данных, такие как операции создания таблицы или изменения данных таблицы. Он также содержит события для инструкций, которые могли бы внести изменения. Двоичный журнал используется в основном для репликации и операции восстановления данных. Как правило, двоичные журналы очищаются, как только этот дескриптор освобождается от службы, резервной копии или набора реплик. Если существует несколько реплик, двоичные журналы ожидают, пока самая медленная реплика будет считывать изменения до очистки. Если вы хотите сохранить двоичные журналы в течение более длительного времени, можно настроить параметр 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_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 для 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 отображаются изменяемые и неизменяемые параметры сервера. Параметры сервера, не изменяемые без изменений, не являются серыми. Если вы хотите настроить немодируемый параметр сервера на уровне сеанса, ознакомьтесь со статьей портал Azure или Azure CLI, чтобы задать параметр на уровне подключения.init_connect

Следующие шаги