Создание MySQL-кластера
MySQL-кластер — это один или несколько хостов базы данных, между которыми можно настроить репликацию. Репликация работает по умолчанию в любом кластере из более чем 1 хоста: хост-мастер принимает запросы на запись, синхронно дублирует изменения в основной реплике и асинхронно — во всех остальных.
Количество хостов, которые можно создать вместе с MySQL-кластером, зависит от выбранного варианта хранилища:
- При использовании сетевых дисков вы можете запросить любое количество хостов (от 1 до пределов текущей квоты).
- При использовании SSD-дисков вместе с кластером можно создать не меньше 3 реплик (минимум 3 реплики необходимо, чтобы обеспечить отказоустойчивость). Если после создания кластера доступных ресурсов каталога останется достаточно, вы можете добавить дополнительные реплики.
По умолчанию Managed Service for MySQL выставляет ограничение на количество подключений к каждому хосту MySQL-кластера как 200 × <количество vCPU на хосте>
. Например, для хоста класса s1.micro значение параметра max_connections
по умолчанию равно 400.
Примечание
Если хранилище баз данных заполнится на 95%, кластер перейдет в режим только чтения. Увеличивайте размер хранилища заранее.
Как создать кластер MySQL
-
В консоли управления выберите каталог, в котором нужно создать кластер БД.
-
Выберите сервис Managed Service for MySQL.
-
Нажмите кнопку Создать кластер.
-
Введите имя кластера в поле Имя кластера. Имя кластера должно быть уникальным в рамках Yandex.Cloud.
-
Выберите окружение, в котором нужно создать кластер (после создания кластера окружение изменить невозможно):
PRODUCTION
— для стабильных версий ваших приложений.PRESTABLE
— для тестирования, в том числе самого сервиса Managed Service for MySQL. В Prestable-окружении раньше появляются новая функциональность, улучшения и исправления ошибок. При этом не все обновления обеспечивают обратную совместимость.
-
Выберите версию СУБД.
-
Выберите класс хостов — он определяет технические характеристики виртуальных машин, на которых будут развернуты хосты БД. Все доступные варианты перечислены в разделе Классы хостов. При изменении класса хостов для кластера меняются характеристики всех уже созданных хостов.
-
В блоке Размер хранилища:
- Выберите тип хранилища — более гибкое сетевое (network-hdd или network-ssd) или более быстрое локальное хранилище (local-ssd). Размер локального хранилища можно менять только с шагом 100 ГБ.
- Выберите объем, который будет использоваться для данных и резервных копий. Подробнее о том, как занимают пространство резервные копии, см. раздел Резервные копии.
-
В блоке База данных укажите атрибуты БД:
- Имя базы данных. Имя БД должно быть уникальным в рамках каталога и содержать только латинские буквы, цифры и подчеркивания.
- Имя пользователя — владельца БД. Имя пользователя должно содержать только латинские буквы, цифры и подчеркивания.
- Пароль пользователя, от 8 до 128 символов.
-
В блоке Хосты выберите параметры хостов БД, создаваемых вместе с кластером (помните, что используя SSD-диски при создании MySQL-кластера можно задать не меньше 3 хостов). Открыв блок Расширенные настройки, вы можете выбрать конкретные подсети для каждого хоста — по умолчанию каждый хост создается в отдельной подсети.
-
При необходимости задайте дополнительные настройки кластера:
-
Начало резервного копирования (UTC) — время по UTC, когда требуется начать резервное копирование кластера (в 24-часовом формате). Если время не задано, резервное копирование начнется в 22:00 UTC.
-
Окно обслуживания — настройки окна технического обслуживания. С их помощью вы можете указать предпочтительное время начала проведения операций по техническому обслуживанию хостов кластера (например, можно выбрать время, когда кластер наименее нагружен запросами):
- Чтобы указать предпочтительное время начала окна технического обслуживания, выберите пункт по расписанию и задайте нужные день недели и час дня в UTC (Coordinated Universal Time), выбрав значения из выпадающих списков.
- Чтобы разрешить проведение операций технического обслуживания в любое время, выберите пункт произвольное.
Операции по техническому обслуживанию могут включать в себя: обновление версии СУБД, применение патчей и так далее.
-
Доступ из DataLens — включите эту опцию, чтобы получить возможность анализировать данные из кластера в сервисе Yandex DataLens. Подробнее о настройке подключения см. в разделе Подключение к DataLens.
-
Доступ из консоли управления — включите эту опцию, чтобы получить возможность выполнять SQL-запросы к базам кластера из консоли управления Yandex.Cloud.
-
-
При необходимости задайте настройки СУБД:
-
Audit log — включает или выключает запись лога аудита MySQL.
По умолчанию запись лога аудита выключена.
Подробнее см. в документации MySQL.
-
Auto increment increment — задает интервал между значениями столбцов с атрибутом
AUTO_INCREMENT
.Минимальное значение —
1
, максимальное значение —65535
, по умолчанию —1
.Подробнее см. в документации MySQL.
-
Auto increment offset — задает начальное значение для столбцов с атрибутом
AUTO_INCREMENT
. Эта настройка игнорируется, если ее значение больше значения настройки Auto increment increment.Минимальное значение —
1
, максимальное значение —65535
, по умолчанию —1
.Подробнее см. в документации MySQL.
-
Binlog cache size — размер кеша (в байтах) для хранения изменений бинарного лога во время транзакции.
Минимальное значение —
4096
(4 КБ), максимальное значение —67108864
(64 МБ), по умолчанию —32768
(32 КБ).Подробнее см. в документации MySQL.
-
Binlog group commit sync delay — задержка перед синхронизацией бинарного лога с диском при операции
COMMIT
для бинарного лога. Чтобы синхронизировать с диском больше транзакций за раз, задайте задержку больше нуля. Это снизит общее время, затрачиваемое на операциюCOMMIT
для группы транзакций.Минимальное значение —
0
(нет задержки), максимальное значение —1000000
(одна секунда), по умолчанию —0
.Подробнее см. в документации MySQL.
-
Binlog row image — способ записи образов строк (row images) в бинарный лог при построчной репликации (row-based replication):
FULL
(по умолчанию) — все столбцы записываются как в образ «до», так и в образ «после»;MINIMAL
— в образ «до» записываются только столбцы, требуемые для идентификации строк, которые нужно изменить; в образ «после» записываются только столбцы, для которых было задано значение с помощью SQL-выражения или операции автоинкремента.NOBLOB
— все столбцы записываются в образы «до» и «после» (как в способеFULL
), за исключением столбцовBLOB
иTEXT
, которые либо не изменились, либо не требуются для идентификации строк.
Подробнее см. в документации MySQL.
-
Binlog rows query log events — включает или выключает запись информационных событий (например, событий лога запросов) в бинарный лог.
По умолчанию запись событий в бинарный лог выключена.
Подробнее см. в документации MySQL.
-
Character set server — кодировка, которую сервер MySQL использует при работе с данными и обмене информацией с клиентами MySQL. Выбор кодировки влияет на работу SQL-функций для манипуляций со строками и другую функциональность.
По умолчанию:
utf8mb4
.Подробнее см. в документации MySQL.
-
Collation server — алгоритм сравнения символов (collation), который сервер MySQL использует при работе с данными и обмене информацией с клиентами MySQL. Выбор алгоритма влияет на работу SQL-функций для сортировки, манипуляций со строками и другую функциональность.
По умолчанию:
utf8mb4_0900_ai_ci
.Подробнее см. в документации MySQL.
-
Default authentication plugin — плагин аутентификации, используемый в кластере Managed Service for MySQL:
mysql_native_password
— метод аутентификации, который использовался в MySQL до внедрения плагинов аутентификации;sha256_password
— аутентификация с использованием алгоритма хэширования SHA-256 для паролей;caching_sha2_password
(по умолчанию) — аналогиченsha256_password
, использует кеширование на стороне сервера для лучшей производительности и предоставляет некоторые дополнительные возможности.
Подробнее см. в документации MySQL.
-
Default time zone — часовой пояс сервера.
По умолчанию:
Europe/Moscow
.Подробнее см. в документации MySQL.
-
Explicit defaults for timestamp — разрешает или запрещает определенные нестандартные варианты поведения для значений по умолчанию и обработку значений
NULL
в столбцахTIMESTAMP
.По умолчанию настройка включена (нестандартное поведение запрещено).
Подробнее см. в документации MySQL.
-
General log — включает или выключает запись основного лога запросов MySQL.
По умолчанию запись основного лога запросов выключена.
Подробнее см. в документации MySQL.
-
Group concat max len — максимальная длина (в байтах) результата функции GROUP_CONCAT().
Минимальное значение —
4
, максимальное значение —33554432
(32 МБ), по умолчанию —1024
(1 КБ).Подробнее см. в документации MySQL
-
Innodb adaptive hash index — включает или выключает адаптивный хэш-индекс InnoDB. Для некоторых видов нагрузки на базу данных может быть полезно отключение этого индекса. Документация MySQL рекомендует провести нагрузочное тестирование на реальных данных, чтобы определить необходимость включения или отключения адаптивного хэш-индекса.
По умолчанию адаптивный хэш-индекс включен.
Подробнее см. в документации MySQL.
-
Innodb buffer pool size — размер буфера InnoDB (в байтах), который используется для кеширования данных таблиц и индексов. Буфер большого размера приводит к снижению количества операций ввода-вывода при многократном обращении к одним и тем же данным в таблице.
Минимальное значение —
5242880
(5 МБ), по умолчанию — 50% от общего размера RAM хоста кластера Managed Service for MySQL.Подробнее см. в документации MySQL.
-
Innodb flush log at trx commit — определяет поведение MySQL для операций подтверждения транзакций (
COMMIT
):0
— логи пишутся и сбрасываются (flush) на диск раз в секунду. В случае сбоя данные транзакций, логи для которых не были сброшены на диск, могут быть утеряны.1
(по умолчанию) — строгое следование принципам ACID. Логи пишутся и сбрасываются на диск при подтверждении каждой транзакции.2
— логи пишутся при подтверждении каждой транзакции, но сбрасываются на диск раз в секунду. В случае сбоя данные транзакций, логи для которых не были сброшены на диск, могут быть утеряны.
Подробнее см. в документации MySQL.
-
Innodb io capacity — количество операций ввода-вывода в секунду (IOPS), доступное всем фоновым операциям InnoDB. Эта настройка влияет на процессы, использующие ввод-вывод (например, сброс данных на диск) и может использоваться для ограничения количества операций ввода-вывода.
Минимальное значение —
100
, максимальное значение —100000
, по умолчанию —200
.Подробнее см. в документации MySQL.
-
Innodb io capacity max — максимальное количество операций ввода-вывода в секунду (IOPS), доступное всем фоновым операциям InnoDB. Если хост не успевает сбрасывать данные на диск, то InnoDB может начать сбрасывать данные на диск чаще, чем установленный настройкой Innodb io capacity порог IOPS, не превышая заданного максимального ограничения на IOPS.
Минимальное значение —
100
, максимальное значение —100000
, по умолчанию —2000
.Подробнее см. в документации MySQL.
-
Innodb lock wait timeout — максимальное время ожидания блокировки строки (в секундах) для транзакции InnoDB. Если время ожидания истекло, то возвращается ошибка, и текущее выражение SQL откатывается (вся транзакция не откатывается).
Значение настройки можно уменьшить для OLTP-приложений и приложений, которые взаимодействуют с пользователем в интерактивном режиме. Значение настройки можно увеличить, если в приложении есть длительные операции, например, ожидающие завершения больших запросов
INSERT
иUPDATE
в процессе трансформации большого массива данных из хранилища данных.Минимальное значение —
1
, максимальное значение —28800
(480 минут или 8 часов), по умолчанию —50
.Подробнее см. в документации MySQL.
-
Innodb log buffer size — размер буфера (в байтах), который InnoDB использует при записи логов на диск. Большой буфер позволяет выполнять большие транзакции без записи лога на диск до подтверждения транзакции, что позволяет экономить ресурсы ввода-вывода.
Минимальное значение —
1048576
(1 МБ), максимальное значение —268435456
(256 МБ), по умолчанию —16777216
(16 МБ).Подробнее см. в документации MySQL.
-
Innodb log file size — размер одного файла redo-логов InnnoDB (в байтах). Чем больше значение, тем реже требуется сбрасывать контрольные точки (checkpoints) на диск, что позволяет экономить ресурсы ввода-вывода. Однако большой размер лог-файлов приводит к более медленному восстановлению после сбоев.
Минимальное значение —
268435456
(256 МБ), максимальное значение —4294967296
(4 ГБ), по умолчанию —268435456
(256 МБ).Подробнее см. в документации MySQL.
-
Innodb numa interleave — включает или выключает политику NUMA Interleave при выделении памяти для буфера InnoDB.
По умолчанию эта политика выключена.
Подробнее см. в документации MySQL.
-
Innodb print all deadlocks — включает или выключает вывод всей информации о взаимных блокировках в лог ошибок. Если эта настройка выключена, то при выполнении команды
SHOW ENGINE INNODB STATUS
будет выведена информация только о последней блокировке.По умолчанию вывод всей информации о взаимных блокировках выключен.
Подробнее см. в документации MySQL.
-
Innodb purge threads — количество потоков ввода-вывода InnoDB, используемых для операций очистки (purge). Увеличение количества этих потоков полезно в системах, где операции манипуляции с данными (
INSERT
,UPDATE
,DELETE
) выполняются над несколькими таблицами.Минимальное значение —
1
, максимальное значение —16
, по умолчанию —4
.Подробнее см. в документации MySQL.
-
Innodb read io threads — количество потоков ввода-вывода InnoDB, используемых для операций чтения.
Минимальное значение —
1
, максимальное значение —16
, по умолчанию —4
.Подробнее см. в документации MySQL.
-
Innodb temp data file max size — максимальный размер временного табличного пространства InnoDB (в байтах).
Минимальное значение —
0
(не использовать временное табличное простанство), максимальное значение —107374182400
(100 ГБ), по умолчанию —0
.Подробнее см. в документации MySQL.
-
Innodb thread concurrency — максимальное число потоков, которые могут исполняться внутри InnoDB.
Минимальное значение —
0
(ограничения отсутствуют), максимальное значение —1000
, по умолчанию —0
.Подробнее см. в документации MySQL.
-
Innodb write io threads — количество потоков ввода-вывода InnoDB, используемых для операций записи.
Минимальное значение —
1
, максимальное значение —16
, по умолчанию —4
.Подробнее см. в документации MySQL.
-
Join buffer size — минимальный размер буфера (в байтах), который используется для:
- сканирования простого индекса;
- сканирования индекса диапазона;
- полного сканирования таблиц (для операций
JOIN
, не использующих индексы).
Один буфер указанного размера выделяется на каждую операцию объединения двух таблиц. Увеличьте значение этой настройки, чтобы ускорить операции объединения таблиц, для которых невозможно добавить индексы.
Минимальное значение —
1024
(1 КБ), максимальное значение —16777216
(16 МБ), по умолчанию —262144
(256 КБ).Подробнее см. в документации MySQL.
-
Long query time — время обработки запроса (в секундах), при превышении которого запрос будет считаться медленным. Не рекомендуется задавать маленькие значения для этой настройки — это может привести к ошибочному расцениванию большинства запросов как медленных.
Минимальное значение —
0
, максимальное значение —3600
(1 час), по умолчанию —0
.Подробнее см. в документации MySQL.
-
Max allowed packet — максимальный размер (в байтах) одного пакета, строки или параметра, отправляемого функцией mysql_stmt_send_long_data().
По умолчанию задан небольшой размер, что позволяет отбрасывать некорректные пакеты, которые обычно больше. Увеличьте значение настройки, если вы используете большие BLOB-столбцы или длинные строки.
Минимальное значение —
1024
(1 КБ), максимальное значение —134217728
(128 МБ), по умолчанию —16777216
(16 МБ).Подробнее см. в документации MySQL.
-
Max connections — максимальное количество одновременных подключений, которые может принять хост MySQL.
Минимальное значение —
10
, максимальное значение —10000
, по умолчанию — 25 соединений на каждый гигабайт RAM хоста кластера за исключением хостов с количеством RAM большим, чем 384 ГБ (например, для хоста класса b2.medium с 4 ГБ RAM значение настройки по умолчанию —100
).Подробнее см. в документации MySQL.
-
Max heap table size — максимальный размер пользовательских MEMORY-таблиц (в байтах). Изменение значения этой настройки не влияет на уже существующие MEMORY-таблицы. Эта настройка также используется совместно с Tmp table size для ограничения размера внутренних таблиц, хранящихся в оперативной памяти.
Минимальное значение —
16384
(16 КБ), максимальное значение —134217728
(128 МБ), по умолчанию —16777216
(16 МБ).Подробнее см. в документации MySQL.
-
Net read timeout — максимальное время ожидания чтения (в секундах) при передаче данных по сети.
Минимальное значение —
1
, максимальное значение —1200
(20 минут), по умолчанию —30
.Подробнее см. в документации MySQL.
-
Net write timeout — максимальное время ожидания записи (в секундах) при передаче данных по сети.
Минимальное значение —
1
, максимальное значение —1200
(20 минут), по умолчанию —60
.Подробнее см. в документации MySQL.
-
Regexp time limit — ограничение на количество шагов при поиске соответствия (match) с помощью REGEXP_LIKE() и других подобных функций для работы с регулярными выражениями. Таким образом, эта настройка влияет на время выполнения косвенно.
Минимальное значение —
0
(нет ограничений), максимальное значение —1048576
. По умолчанию:0
.Подробнее см. в документации MySQL.
-
Rpl semi sync master wait for slave count — количество реплик, от которых мастер ожидает ответа при полусинхронной репликации, прежде чем подтвердить транзакцию (
COMMIT
).Минимальное значение —
1
, максимальное значение —2
, по умолчанию —1
.Подробнее см. в документации MySQL.
-
Slave parallel type — политика для определения того, какие транзакции могут выполняться параллельно на реплике при включенной многопоточной репликации (такая репликация включается настройкой Slave parallel workers):
LOGICAL_CLOCK
— транзакции, являющиеся частью группового коммита для одного и того же бинарного лога на источнике, выполняются параллельно на реплике.DATABASE
(по умолчанию) — транзакции, которые изменяют разные базы данных, выполняются параллельно.
Подробнее см. в документации MySQL.
-
Slave parallel workers — устанавливает количество потоков для параллельного выполнения транзакций репликации на реплике.
Минимальное значение —
0
(многопоточная репликация на реплике выключена), максимальное значение —64
, по умолчанию —0
.Подробнее см. в документации MySQL.
-
Sort buffer size — размер буфера (в байтах), который используется для сортировок в памяти.
Минимальное значение —
32768
(32 КБ), максимальное значение —16777216
(16 МБ), по умолчанию —262144
(256 КБ).Подробнее см. в документации MySQL.
-
Sql mode — режимы SQL для сервера MySQL:
-
ALLOW_INVALID_DATES — не выполнять полную проверку корректности дат. В этом режиме проверяется, что месяц находится в диапазоне от 1 до 12, а день в диапазоне от 1 до 31. Некорректные даты (например,
2004-04-31
) преобразуются в0000-00-00
с выдачей предупреждения (warning). -
ANSI_QUOTES — воспринимать кавычки
"
как кавычки для идентификаторов, но не для строк. В этом режиме для строк следует использовать одинарные кавычки'
вместо двойных кавычек"
. -
ERROR_FOR_DIVISION_BY_ZERO — операция деления на ноль возвращает
NULL
с выдачей предупреждения (warning). Этот режим SQL является устаревшим (deprecated). -
HIGH_NOT_PRECEDENCE — повышает приоритет операции отрицания (
NOT
) при разборе логических выражений. В этом режиме выражениеNOT a BETWEEN b AND c
будет интерпретировано как(NOT a) BETWEEN b AND c
вместоNOT (a BETWEEN b AND c)
. -
IGNORE_SPACE — разрешает пробелы между именем функции и открывающей скобкой
(
. Это приводит к тому, что имена встроенных функций интерпретируются как ключевые слова. Идентификаторы объектов, которые совпадают с именами таких функций, должны быть окружены кавычками. -
NO_AUTO_VALUE_ON_ZERO — только вставка
NULL
в столбец с атрибутомAUTO_INCREMENT
приводит к генерации нового значения для столбца. Обычно новое значение генерируется при вставке0
илиNULL
, поэтому этот режим полезен, если в таком столбце требуется явно хранить значение0
. -
NO_BACKSLASH_ESCAPES — выключает использование обратного слеша
\
в качестве escape-символа. Обратный слеш в этом режиме воспринимается как обычный символ. -
NO_DIR_IN_CREATE — директивы
INDEX DIRECTORY
иDATA DIRECTORY
игнорируются при создании таблицы. -
NO_ENGINE_SUBSTITUTION — не подставлять движок по умолчанию автоматически в случае недоступности движка, указанного в
CREATE TABLE
илиALTER TABLE
, и выдать соответствующую ошибку. -
NO_UNSIGNED_SUBTRACTION — разрешен отрицательный результат при вычитании целых чисел, одно из которых беззнаковое (unsigned).
-
NO_ZERO_DATE — влияет на использование даты
0000-00-00
:- Если strict SQL mode выключен: использование даты
0000-00-00
допустимо, вставка такой даты приведет к выдаче предупреждения (warning). - Если strict SQL mode включен: использование даты
0000-00-00
недопустимо, попытка вставки такой даты приведет к ошибке.
Этот режим SQL является устаревшим (deprecated).
- Если strict SQL mode выключен: использование даты
-
NO_ZERO_IN_DATE — влияет на использование дат с нулевыми месяцем или днем:
- Если strict SQL mode выключен: даты с нулевыми месяцем или днем вставляются в виде
0000-00-00
с выдачей предупреждения (warning). - Если strict SQL mode включен: использование даты с нулевыми месяцам или днем недопустимо, попытка вставки такой даты приведет к ошибке.
Этот режим SQL является устаревшим (deprecated).
См. также: NO_ZERO_DATE.
- Если strict SQL mode выключен: даты с нулевыми месяцем или днем вставляются в виде
-
ONLY_FULL_GROUP_BY — запрещает выполнение запросов, в которых
SELECT
,HAVING
илиORDER BY
ссылаются на неагрегированные столбцы, которые не упомянуты вGROUP BY
(поведение в стиле SQL-92). -
PAD_CHAR_TO_FULL_LENGTH — выравнивать строки в столбцах
CHAR
пробелами до полной длины. Это не распространяется на столбцыVARCHAR
. -
PIPES_AS_CONCAT — воспринимать
||
как оператор конкатенации (эквивалент CONCAT()), а не синоним оператора OR. -
REAL_AS_FLOAT — воспринимать
REAL
как синоним дляFLOAT
(по умолчанию MySQL воспринимаетREAL
как синоним дляDOUBLE
). -
STRICT_ALL_TABLES — включить строгий режим (strict SQL mode) для всех движков.
-
STRICT_TRANS_TABLES — включить строгий режим (strict SQL mode) для всех транзакционных движков и, если возможно, для нетранзакционных движков.
-
TIME_TRUNCATE_FRACTIONAL — включает обрезку дробной части при вставке значений
TIME
,DATE
илиTIMESTAMP
в столбец, у которого меньшее число знаков в дробной части (по умолчанию MySQL округляет значение до нужного количества знаков, а не обрезает). -
ANSI — комбинация режимов:
REAL_AS_FLOAT
;PIPES_AS_CONCAT
;ANSI_QUOTES
;IGNORE_SPACE
;ONLY_FULL_GROUP_BY
.
-
TRADITIONAL — комбинация режимов:
STRICT_ALL_TABLES
;STRICT_TRANS_TABLES
;NO_ZERO_DATE
;NO_ZERO_IN_DATE
;ERROR_FOR_DIVISION_BY_ZERO
;NO_ENGINE_SUBSTITUTION
;
Можно выбрать несколько режимов из списка или полностью выключить все настройки SQL Mode.
По умолчанию используется следующий набор режимов SQL:
ERROR_FOR_DIVISION_BY_ZERO
;NO_ENGINE_SUBSTITUTION
;NO_ZERO_DATE
;NO_ZERO_IN_DATE
;ONLY_FULL_GROUP_BY
;STRICT_TRANS_TABLES
.
Подробнее см. в документации MySQL.
-
-
Sync binlog — частота синхронизации бинарного лога с диском:
0
— синхронизация отключена, MySQL полагается на операционную систему, которая периодически сбрасывает (flush) содержимое бинарного лога на диск, как для любого другого файла. Этот способ обеспечивает максимальную производительность. Данные могут быть утеряны в случае сбоя питания или операционной системы: транзакции могут быть подтверждены, но еще не синхронизированы с бинарным логом.1
— бинарный лог синхронизируется с диском перед подтверждением транзакций. Это наиболее безопасный способ, который, однако, может отрицательно влиять на производительность из-за большого количества операций записи. В случае сбоя питания или операционной системы транзакции, не попавшие в бинарный лог, находятся в состоянии подготовки (prepared state). Это позволяет автоматически восстановиться после сбоя и откатить (rollback) транзакции. Гарантируется, что ни одна транзакция из бинарного лога не будет утеряна.N
— бинарный лог синхронизируется с диском после сбораN
групп коммита (commit groups) для бинарного лога. В случае сбоя питания или операционной системы транзакции могут быть подтверждены, но еще не синхронизированы с бинарным логом. Этот способ может отрицательно влиять на производительность из-за большого количества операций записи. Чем выше значениеN
, тем выше и производительность, и риск потери данных.
Минимальное значение —
0
, максимальное значение —4096
, по умолчанию —1
.Подробнее см. в документации MySQL.
-
Table definition cache — количество определений таблиц, которые можно поместить в соответствующий кеш. Если в базе данных большое количество таблиц, увеличьте значение этой настройки, чтобы повысить скорость открытия таблиц.
Минимальное значение —
400
, максимальное значение —524288
, по умолчанию —2000
.Подробнее см. в документации MySQL.
-
Table open cache — размер кеша открытых таблиц для всех потоков. Если значение переменной Opened tables велико и вы редко используете FLUSH_TABLES, увеличьте значение настройки.
Увеличение значения этой настройки требует увеличения количества файловых дескрипторов для сервера MySQL.
Минимальное значение —
400
, максимальное значение —524288
, по умолчанию —4000
.Подробнее см. в документации MySQL.
-
Table open cache instances — для повышения масштабируемости кеш открытых таблиц может быть разбит на более мелкие сегменты. Эта настройка задает количество таких сегментов.
Минимальное значение —
1
, максимальное значение —32
, по умолчанию —16
.Подробнее см. в документации MySQL.
-
Thread cache size — количество потоков, которые кешируются для обработки новых сетевых соединений. При установке нового подключения сначала используются потоки из кеша, а потом создаются новые. Увеличьте значение этой настройки, чтобы повысить производительность в случае, когда устанавливается большое количество новых соединений.
Минимальное значение —
10
, максимальное значение —10000
, по умолчанию —10
.Подробнее см. в документации MySQL.
-
Thread stack — размер стека (в байтах) для каждого потока. Значение по умолчанию достаточно велико, чтобы обеспечить нормальную работу MySQL. Слишком маленькое значение настройки ограничивает сложность SQL-выражений, глубину рекурсии для хранимых процедур и другие параметры, связанные с потреблением памяти.
Минимальное значение —
131072
(128 КБ), максимальное значение —16777216
(16 МБ), по умолчанию —196608
(192 КБ).Подробнее см. в документации MySQL.
-
Tmp table size — максимальный размер временной таблицы в памяти (в байтах). При превышении этого размера таблица будет помещена на диск. Эта настройка не влияет на пользовательские MEMORY-таблицы. Увеличьте значение настройки, если вы выполняете много сложных запросов
GROUP BY
и хосты имеют достаточно оперативной памяти.Минимальное значение —
1024
(1 КБ), максимальное значение —134217728
(128 МБ), по умолчанию —16777216
(16 МБ).Подробнее см. в документации MySQL.
-
Transaction isolation — уровень изоляции транзакций по умолчанию:
READ-COMMITTED
— запрос видит только те строки, которые были зафиксированы до начала его выполнения.REPEATABLE-READ
— все запросы в текущей транзакции видят только те строки, которые были зафиксированы перед первым выполненным в этой транзакции запросом на выборку или изменение данных.SERIALIZABLE
— уровень аналогиченREPEATABLE-READ
, за исключением того, что InnoDB неявно конвертируетSELECT
вSELECT ... FOR SHARE
, если autocommit выключен. Если autocommit включен, тоSELECT
находится в своей собственной транзакции в режимеread only
и может быть сериализован.
Подробнее см. в документации MySQL.
-
-
Нажмите кнопку Создать кластер.
Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы создать кластер:
-
Проверьте, есть ли в каталоге подсети для хостов кластера:
$ yc vpc subnet list
Если ни одной подсети в каталоге нет, создайте нужные подсети в сервисе VPC.
-
Посмотрите описание команды CLI для создания кластера:
$ yc managed-mysql cluster create --help
-
Укажите параметры кластера в команде создания:
$ yc managed-mysql cluster create \ --name=<имя кластера> \ --environment <окружение, prestable или production> \ --network-name <имя сети> \ --host zone-id=<зона доступности>,subnet-id=<идентификатор подсети> \ --mysql-version <версия MySQL> \ --resource-preset <класс хоста> \ --user name=<имя пользователя>,password=<пароль пользователя> \ --database name=<имя базы данных>
Идентификатор подсети
subnet-id
необходимо указывать, если в выбранной зоне доступности создано 2 и больше подсетей.
Terraform позволяет быстро создать облачную инфраструктуру в Yandex.Cloud. Состав инфраструктуры определяется с помощью конфигурационных файлов, в которых указываются требуемые облачные ресурсы и их параметры.
Если у вас ещё нет Terraform, установите его и настройте провайдер.
Чтобы создать кластер:
-
Опишите в конфигурационном файле параметры ресурсов, которые необходимо создать:
- Кластер базы данных — описание кластера и его хостов.
- Сеть — описание облачной сети, в которой будет расположен кластер. Если подходящая сеть у вас уже есть, описывать ее повторно не нужно.
- Подсети — описание подсетей, к которым будут подключены хосты кластера. Если подходящие подсети у вас уже есть, описывать их повторно не нужно.
Пример структуры конфигурационного файла:
resource "yandex_mdb_mysql_cluster" "<имя кластера>" { name = "<имя кластера>" environment = "<окружение, PRESTABLE или PRODUCTION>" network_id = "<идентификатор сети>" version = "<версия MySQL: 5.7 или 8.0>" resources { resource_preset_id = "<класс хоста>" disk_type_id = "<тип хранилища>" disk_size = "<размер хранилища в гигабайтах>" } database { name = "<имя базы данных>" } user { name = "<имя пользователя>" password = "<пароль пользователя>" permission { database_name = "<имя базы данных>" roles = ["ALL"] } } host { zone = "<зона доступности>" subnet_id = "<идентификатор подсети>" } } resource "yandex_vpc_network" "<имя сети>" { name = "<имя сети>" } resource "yandex_vpc_subnet" "<имя подсети>" { name = "<имя подсети>" zone = "<зона доступности>" network_id = "<идентификатор сети>" v4_cidr_blocks = ["<диапазон>"] }
Более подробную информацию о ресурсах, которые вы можете создать с помощью Terraform, см. в документации провайдера.
-
Проверьте корректность конфигурационных файлов.
-
В командной строке перейдите в каталог, в котором вы создали конфигурационный файл.
-
Выполните проверку с помощью команды:
terraform plan
Если конфигурация описана верно, в терминале отобразится список создаваемых ресурсов и их параметров. Если в конфигурации есть ошибки, Terraform на них укажет. Это проверочный этап: ресурсы не будут созданы.
-
-
Создайте кластер.
-
Если в конфигурации нет ошибок, выполните команду:
terraform apply
-
Подтвердите создание ресурсов.
После этого в указанном каталоге будут созданы все требуемые ресурсы, а в терминале отобразятся IP-адреса виртуальных машин. Проверить появление ресурсов и их настройки можно в консоли управления.
-
Примеры
Создание кластера с одним хостом
Допустим, нужно создать MySQL-кластер и сеть для него со следующими характеристиками:
- С именем
my-mysql
. - Версии
8.0
. - В окружении
PRESTABLE
. - В облаке с идентификатором
b1gq90dgh25bebiu75o
. - В каталоге
myfolder
. - В новой сети
mynet
. - С одним хостом класса
s2.micro
в новой подсетиmysubnet
, в зоне доступностиru-central1-c
. Подсетьmysubnet
будет иметь диапазон10.5.0.0/24
. - С быстрым сетевым хранилищем (
network-ssd
) объемом 20 ГБ. - С одним пользователем (
user1
), с паролемuser1user1
. - С одной базой данных
db1
, в которой пользовательuser1
имеет полные права (эквивалентGRANT ALL PRIVILEGES on db1.*
).
Конфигурационный файл для такого кластера выглядит так:
provider "yandex" {
token = "<OAuth или статический ключ сервисного аккаунта>"
cloud_id = "b1gq90dgh25bebiu75o"
folder_id = "${data.yandex_resourcemanager_folder.myfolder.id}"
zone = "ru-central1-c"
}
resource "yandex_mdb_mysql_cluster" "my-mysql" {
name = "my-mysql"
environment = "PRESTABLE"
network_id = "${yandex_vpc_network.mynet.id}"
version = "8.0"
resources {
resource_preset_id = "s2.micro"
disk_type_id = "network-ssd"
disk_size = 20
}
database {
name = "db1"
}
user {
name = "user1"
password = "user1user1"
permission {
database_name = "db1"
roles = ["ALL"]
}
}
host {
zone = "ru-central1-c"
subnet_id = "${yandex_vpc_subnet.mysubnet.id}"
}
}
resource "yandex_vpc_network" "mynet" { name = "mynet" }
resource "yandex_vpc_subnet" "mysubnet" {
name = "mysubnet"
zone = "ru-central1-c"
network_id = "${yandex_vpc_network.mynet.id}"
v4_cidr_blocks = ["10.5.0.0/24"]
}