Использование движка хранения S3

Движок хранения S3 является только для чтения и позволяет архивировать таблицы MariaDB в Amazon S3 или в любом стороннем общедоступном или частном облаке, реализующем API S3 (которых много), но при этом они остаются доступными для чтения в MariaDB.

Установка плагина

Начиная с MariaDB 10.5.7, движок хранения S3 имеет текущую степень зрелости «гамма», поэтому следующий шаг можно пропустить.

В более ранних версиях, когда степень зрелости была «альфа», он не будет загружаться по умолчанию в стабильной версии сервера из-за значения переменной plugin_maturity по умолчанию. Установите значение alpha (или ниже) в вашем файле конфигурации, чтобы разрешить установку плагина:

[mysqld]
plugin-maturity = alpha

и перезапустите сервер.

Теперь установите библиотеку плагина, например:

INSTALL SONAME 'ha_s3';

Если библиотека недоступна, например:

INSTALL SONAME 'ha_s3';
ERROR 1126 (HY000): Can't open shared library '/var/lib/mysql/lib64/mysql/plugin/ha_s3.so' 
  (errno: 13, cannot open shared object file: No such file or directory)

вам может потребоваться установить отдельный пакет для движка хранения S3, например:

shell> yum install MariaDB-s3-engine

Перемещение данных в S3

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

ALTER TABLE old_table ENGINE=S3 COMPRESSION_ALGORITHM=zlib

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

ALTER TABLE s3_table ENGINE=INNODB

Новые параметры для ALTER TABLE

• S3_BLOCK_SIZE : Установлено в 4М по умолчанию. Это размер блока для всех страниц индексов и данных, хранящихся в S3.
• COMPRESSION_ALGORITHM : Установлено в 'none' по умолчанию. Какой алгоритм сжатия использовать для блоков, хранящихся в S3. Доступные параметры: none или zlib.

ALTER TABLE можно использовать для таблиц S3 в обычном режиме для добавления столбцов или изменения определений столбцов.

Параметры запуска mysqld для S3

Чтобы использовать S3 для хранения, необходимо *обязательно* указать, как получить доступ к S3 и где хранятся данные в S3:

• s3_access_key: Ключ доступа AWS для доступа к данным
• s3_secret_key: Секретный ключ AWS для доступа к данным
• s3_bucket: Ведро AWS, в котором должны храниться данные. Все данные таблиц MariaDB хранятся в этом ведре.
• s3_region: Регион AWS, в котором должны храниться данные.

Если вы используете службу S3, которая использует HTTP для подключения (например, https://min.io/), вам также необходимо установить следующие переменные:

• s3_port: Номер порта для подключения (0 — использовать значение по умолчанию)
• s3_use_http: Если значение истинно, используется протокол HTTP

Если вы собираетесь использовать конфигурацию с первичным и вторичным серверами, обратите внимание на следующие переменные:

• s3_replicate_alter_as_create_select: При преобразовании таблицы S3 в локальную таблицу логируйте все строки в двоичный журнал. Значение по умолчанию — TRUE. Это позволяет реплике реплицировать CREATE TABLE .. SELECT FROM s3_table даже если у реплики нет доступа к исходному s3_table.
• s3_slave_ignore_updates: Должно быть установлено, если первичный и вторичный серверы используют один и тот же экземпляр S3. Это сообщает реплике, что она может игнорировать любые обновления таблиц S3, поскольку они уже применены на первичном сервере. Значение по умолчанию — FALSE.

Вышеуказанные значения по умолчанию предполагают, что первичный и вторичный серверы не используют один и тот же экземпляр S3.

Другие, менее важные параметры:

• s3_host_name: Имя хоста для службы S3. По умолчанию — "s3.amazonaws.com", служба Amazon S3.
• s3_protocol_version: Протокол, используемый для связи с S3. Один из "Auto", "Amazon" или "Original", где "Auto" — значение по умолчанию. Если при подключении к другому поставщику услуг возникают ошибки, например "8 Access Denied", попробуйте изменить этот параметр. Причина существования этой переменной заключается в том, что Amazon изменил некоторые части протокола S3 с момента его первоначального введения, а другие поставщики услуг по-прежнему используют исходный протокол.
• s3_block_size: Установлено в 4М по умолчанию. Это размер блока по умолчанию для таблицы, если не указано в CREATE TABLE.
• s3_pagecache_buffer_size: По умолчанию 128М. Размер буфера, используемого для блоков данных и индексов для таблиц S3. Увеличьте его для лучшего управления индексами (для всех чтений и нескольких записей) до максимально возможного значения.

И, наконец, некоторые параметры, которые, вероятно, вам никогда не понадобятся:

• s3_pagecache_age_threshold : По умолчанию 300: Характеризует количество обращений к горячему блоку, которое он должен оставаться неиспользуемым, прежде чем его можно будет перевести в тепловой блок. Указывает процентное соотношение этого количества обращений к общему количеству блоков в кэше страниц.
• s3_pagecache_division_limit: По умолчанию 100. Минимальный процент тепловых блоков в кэше ключей.
• s3_pagecache_file_hash_size: По умолчанию 512. Количество ведер хеширования для открытых файлов. Если у вас открыто много файлов S3, вы должны увеличить это значение для ускорения сброса изменений. Хорошее значение — примерно 1/10 от количества возможных открытых файлов S3.
• s3_debug: По умолчанию 0. Создаёт файл трассировки из libmarias3 в stderr (mysqld.err) для отладки протокола S3.

Типичная запись в my.cnf для подключения к службе Amazon S3

[mariadb]
s3=ON
s3-bucket=mariadb
s3-access-key=xxxx
s3-secret-key=xxx
s3-region=eu-north-1
s3-host-name=s3.amazonaws.com
# The following is useful if you want to use minio as a S3 server. (https://min.io/)
#s3-port=9000
#s3-use-http=ON

# Primary and replica share same S3 tables.
s3-slave-ignore-updates=1

[aria_s3_copy]
s3-bucket=mariadb
s3-access-key=xxxx
s3-secret-key=xxx
s3-region=eu-north-1
s3-host-name=s3.amazonaws.com
# The following is useful if you want to use minio as a S3 server. (https://min.io/)
#s3-port=9000
#s3-use-http=ON

Типичная запись в my.cnf для подключения к серверу S3 minio

[mariadb]
s3=ON
s3-host-name="127.0.0.1"
s3-bucket=storage-engine
s3-access-key=minio
s3-secret-key=minioadmin
s3-port=9000
s3-use-http=ON

[aria_s3_copy]
s3=ON
s3-host-name="127.0.0.1"
s3-bucket=storage-engine
s3-access-key=minio
s3-secret-key=minioadmin
s3-port=9000
s3-use-http=ON

Типичный сценарий использования таблиц S3

Типичный сценарий использования — это наличие таблиц, которые со временем становятся достаточно неактивными, но по-прежнему важны, поэтому их нельзя удалять. В этом случае можно переместить такую таблицу в архивную службу, доступную через API S3.

Обратите внимание, что S3 — это API облачного хранения объектов, определенный Amazon AWS. Часто все облачное хранилище объектов Amazon называют S3. В контексте движка хранения архива S3 речь идет именно об API, который определяет способ хранения объектов в облачной службе, будь то Amazon или кто-то другой. Например, OpenStack предоставляет API S3 для хранения объектов.

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

Доступные операции для таблиц S3

• ALTER TABLE S3 поддерживает все типы, ключи и другие параметры, которые поддерживает движок Aria. Также можно выполнить ALTER TABLE для таблицы S3, чтобы добавить или изменить столбцы и т. д.
• DROP TABLE
• SELECT Любые операции SELECT, которые вы можете выполнить с обычной таблицей, должны работать и с таблицей S3.
• SHOW TABLES отобразит все таблицы, которые существуют в текущем определённом месте хранения S3.
• Таблицы S3 могут быть частью разделов. См. Раздел ниже.

Обнаружение

Движок хранения S3 поддерживает полное обнаружение таблиц MariaDB. Это означает, что если движок хранения S3 включён и правильно настроен, таблицы, хранящиеся в S3, будут автоматически обнаружены при обращении к ним с помощью SHOW TABLES, SELECT или любой другой операции, пытающейся к ним обратиться. В случае SELECT файл .frm из S3 будет скопирован в локальное хранилище для ускорения будущих обращений.

Когда таблица S3 открывается впервые (она не находится в кэше таблиц) и есть локальный файл .frm, движок S3 проверяет, актуален ли он, и, если нет, обновляет или удаляет файл .frm.

Это означает, что если определение таблицы в S3 изменится, а оно находится в локальном кэше, необходимо выполнить FLUSH TABLES чтобы MariaDB заметила изменения и обновила файл .frm.

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

Обнаружение таблиц S3 не выполняется для таблиц в базе данных mysql, чтобы ускорить запуск mysqld и повысить безопасность.

Репликация

S3 работает с репликацией. Репликацию можно использовать в двух разных сценариях:

• Основной и реплицируемый серверы используют одно и то же хранилище S3. В этом случае основной сервер внесёт все изменения в данные S3, а реплицируемый сервер проигнорирует любые изменения в потоке репликации данных S3. Этот сценарий достигается установкой s3_slave_ignore_updates в 1.
• Основной и реплицируемый серверы не используют одно и то же хранилище S3, или реплицируемый сервер использует другой движок хранения для таблиц S3. Этот сценарий достигается установкой s3_slave_ignore_updates в 0.

aria_s3_copy

aria_s3_copy — это внешний инструмент, который можно использовать для копирования таблиц Aria в S3 и из S3. Используйте aria_s3_copy --help для получения опций использования.

mariadb-dump

• mariadb-dump по умолчанию игнорирует таблицы S3. Если mariadb-dump выполняется с опцией --copy-s3-tables, результирующий файл будет содержать оператор CREATE для аналогичной таблицы Aria, за которым следуют данные таблицы и завершается ALTER TABLE xxx ENGINE=S3.

ANALYZE TABLE

Начиная с MariaDB 10.5.14, ANALYZE TABLE поддерживается для таблиц S3. Поскольку таблицы S3 являются только для чтения, обычный ANALYZE TABLE ничего не сделает. Однако использование ANALYZE TABLE table_name PERSISTENT FOR... теперь будет работать.

CHECK TABLE

Начиная с MariaDB 10.5.14, CHECK TABLE будет работать. Поскольку таблицы S3 только для чтения, вероятность их повреждения очень низка. Единственный известный способ повреждения таблицы S3 — повреждение исходной таблицы, скопированной в S3, или прерывание процесса копирования исходной таблицы в S3.

Текущие ограничения

• mysql-test-run по умолчанию не тестирует движок S3, так как мы не можем встраивать ключи AWS в mysql-test-run.
• Реплики не должны обращаться к таблицам S3 во время их изменения (ALTER)! Это связано с тем, что блокировка между серверами в S3 не реализована. Однако после изменения таблицы (как исходной таблицы S3, так и разделяемой таблицы S3) на основном сервере реплика заметит это при следующем доступе и обновит своё локальное определение.

Ограничения в ALTER .. PARTITION

Все операции ALTER PARTITION поддерживаются для таблиц S3 с разбиением, за исключением:

• REBUILD PARTITION
• TRUNCATE PARTITION
• REORGANIZE PARTITION

Соображения по производительности

В зависимости от скорости подключения к вашему поставщику S3, могут наблюдаться заметные замедления в некоторых операциях.

Обнаружение

Поскольку S3 поддерживает обнаружение (автоматическое предоставление доступных таблиц, которые находятся в S3), это может вызвать небольшие проблемы с производительностью, если движок S3 включен. Разбиение таблиц S3 также поддерживает обнаружение.

• CREATE TABLE немного медленнее, так как движку S3 нужно проверить, существует ли таблица S3, которую нужно создать.
• Запросы к таблицам information_schema медленнее, так как S3 должен проверить, есть ли новые таблицы в S3.
• Удаление несуществующих таблиц происходит медленнее, так как S3 должен проверить, существует ли таблица в S3.

При доступе к существующим таблицам на сервере снижения производительности нет. Первый доступ к таблице S3 скопирует файл .frm из S3 на локальный диск, ускоряя будущие обращения к таблице.

Кэширование

• Доступ к таблице в S3 может занять некоторое время, особенно если вы используете большие пакеты (s3_block_size). Однако второй доступ к тем же данным должен быть быстрым, поскольку он кэшируется в кэше страниц S3.

Что можно попробовать для повышения производительности

Если у вас проблемы с производительностью движка S3, вот что можно попробовать:

• Уменьшение s3_block_size. Это можно сделать как глобально, так и для каждой таблицы.
• Использование COMPRESSION_ALGORITHM=zlib при создании таблицы. Это уменьшит количество данных, передаваемых из S3 в локальный кэш.
• Увеличение размера кэша страниц S3: s3_pagecache_buffer_size

Также попробуйте выполнить запрос дважды, чтобы проверить, не связана ли проблема с некорректным кэшированием данных. После кэширования данных на локальном уровне производительность должна быть отличной.

Идеи будущего развития

• Хранение ключей AWS и региона в таблице mysql.servers (как в Spider и FederatedX). Это позволит использовать разные таблицы на разных серверах S3.
• Хранение ведра S3, ключа доступа и секретного ключа в кэше для более эффективного повторного использования подключений. Это сэкономит память и ускорит доступ к S3, поскольку можно будет использовать старые подключения.

Устранение неполадок S3 в SELinux

Если возникают ошибки, такие как:

ERROR 3 (HY000): Got error from put_object(bubu/produkt/frm): 5 Couldn't connect to server

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

Поиск портов, разрешённых для MariaDB:

$ sudo semanage port -l | grep mysqd_port_t
mysqld_port_t                tcp   1186, 3306, 63132-63164

Предположим, вы хотите разрешить MariaDB подключение к порту 32768:

$ sudo semanage port -a -t mysqld_port_t -p tcp 32768

Вы можете проверить, что новый порт 32768 теперь разрешён для MariaDB:

$ sudo semanage port -l | grep mysqd_port_t
mysqld_port_t                tcp   32768,1186, 3306, 63132-63164

См. также

• Внутренности движка хранения S3