systemd

systemd — это sysVinit замена, которая является менеджером служб по умолчанию в следующих дистрибутивах Linux:

• RHEL 7 и выше
• CentOS 7 и выше
• Fedora 15 и выше
• Debian 8 и выше
• Ubuntu 15.04 и выше
• SLES 12 и выше
• OpenSUSE 12.2 и выше

Файл systemd единицы MariaDB включён в пакеты сервера для RPM и DEBs. Он также включён в определённые бинарные tar-архивы.

Имя службы — mariadb.service.

Когда MariaDB запускается с файлом единицы systemd, он непосредственно запускает процесс mariadbd как пользователь mysql. В отличие от sysVinit, процесс mariadbd не запускается с mysqld_safe. Вследствие этого параметры не будут считываться из [mysqld_safe] группы параметров из файлов параметров.

Содержание файла единицы службы MariaDB

Содержание файла mariadb.service можно изучить с помощью systemctl show mariadb.service.

Взаимодействие с процессом сервера MariaDB

С сервисом можно взаимодействовать, используя команду systemctl.

Запуск процесса сервера MariaDB при загрузке

Службу MariaDB systemd можно настроить на запуск при загрузке, выполнив следующее:

sudo systemctl enable mariadb.service

Запуск процесса сервера MariaDB

Службу MariaDB systemd можно запустить, выполнив следующее:

sudo systemctl start mariadb.service

Файл единицы systemd MariaDB по умолчанию имеет таймаут запуска около 90 секунд на большинстве систем. Если определённые задачи запуска, такие как восстановление после сбоя, занимают больше этого значения таймаута запуска по умолчанию, то systemd предположит, что mariadbd не удалось запуститься, что заставляет systemd убить процесс mariadbd. Чтобы обойти это, можно перенастроить единицу MariaDB systemd на использование бесконечного таймаута.

Обратите внимание, что systemd 236 добавил переменную среды EXTEND_TIMEOUT_USEC, которая позволяет службам продлить таймаут запуска во время длительных процессов. Начиная с MariaDB 10.1.33, MariaDB 10.2.15 и MariaDB 10.3.6, на системах с версиями systemd, которые её поддерживают, MariaDB использует эту функцию для продления таймаута запуска во время определённых длительных процессов запуска. Поэтому, если вы используете systemd 236 или более позднюю версию, то вам не нужно вручную переопределять TimeoutStartSec, даже если ваши задачи запуска, такие как восстановление после сбоя, выполняются дольше, чем заданное значение. Подробнее см. MDEV-14705.

Остановка процесса сервера MariaDB

Службу MariaDB systemd можно остановить, выполнив следующее:

sudo systemctl stop mariadb.service

Перезапуск процесса сервера MariaDB

Службу MariaDB systemd можно перезапустить, выполнив следующее:

sudo systemctl restart mariadb.service

Проверка статуса процесса сервера MariaDB

Статус службы MariaDB systemd можно получить, выполнив следующее:

sudo systemctl status mariadb.service

Взаимодействие с несколькими процессами сервера MariaDB

Шаблонный файл единицы systemd с именем mariadb@.service установлен в INSTALL_SYSTEMD_UNITDIR на некоторых системах. Обратитесь к разделу Поиск файла единицы службы MariaDB, чтобы узнать, на какую директорию он ссылается в каждом дистрибутиве.

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

sudo systemctl start mariadb@node1.service

Конфигурация по умолчанию для нескольких экземпляров в версии 10.4 и новее

systemd также будет искать файл параметров для конкретного экземпляра MariaDB, основываясь на имени экземпляра.

Он будет использовать .%I в качестве настраиваемого суффикса группы параметров, который добавляется к любой группе параметров сервера в любом включенном по умолчанию файле конфигурации.

Во всех дистрибутивах %I является именем экземпляра MariaDB. В приведенном выше node1 случае он будет использовать файл параметров по пути /etc/mynode1.cnf.

При использовании нескольких экземпляров каждый экземпляр, конечно же, также потребует собственный datadir, socket и , port (если skip_networking is specified). As mariadb-install-db#option-groups reads the same sections as the server, and ExecStartPre= run mariadb-install-db within the service, the instances are autocreated if there is sufficient priviledges.

Чтобы использовать конфигурацию 10.3 в версии 10.4 или новее и последующую настройку в редакторе после выполнения sudo systemctl edit mariadb@.service:

[Unit]
ConditionPathExists=

[Service]
Environment='MYSQLD_MULTI_INSTANCE=--defaults-file=/etc/my%I.cnf'

Настройка нескольких экземпляров в версии 10.4 и новее

Поскольку пользователи могут хотеть делать множество различных вещей со своими несколькими экземплярами, мы предоставили способ, позволяющий пользователю определить, как они хотят запустить свои несколько экземпляров. Переменная среды systemd MYSQLD_MULTI_INSTANCE может быть установлена на любое значение, которое будут распознавать mariadbd и mariadb-install-db.

Среда хостинга, где каждый пользователь имеет свой собственный экземпляр, может выглядеть следующим образом (с sudo systemctl edit mariadb@.service):

[Service]
ProtectHome=false
Environment='MYSQLD_MULTI_INSTANCE=--defaults-file=/home/%I/my.cnf \
                        --user=%I \
                        --socket=/home/%I.sock \ 
                        --datadir=/home/%I/mariadb_data \
                        --skip-networking'

Здесь имя экземпляра — это unix-пользователь службы.

Настройка нескольких экземпляров в версии 10.3 и более ранних

systemd также будет искать файл параметров для конкретного экземпляра MariaDB, основываясь на имени экземпляра. По умолчанию он будет искать файл параметров в каталоге, определённом во время сборки параметром INSTALL_SYSCONF2DIR, предоставленным cmake.

Например, в RHEL, CentOS, Fedora и других похожих дистрибутивах Linux INSTALL_SYSCONF2DIR определён как /etc/my.cnf.d/, поэтому он будет искать файл параметров, который соответствует формату:

• /etc/my.cnf.d/my%I.cnf

А в Debian, Ubuntu и других похожих дистрибутивах INSTALL_SYSCONF2DIR определён как /etc/mysql/conf.d//, поэтому он будет искать файл параметров, который соответствует формату:

• /etc/mysql/conf.d/my%I.cnf

Во всех дистрибутивах %I — это имя экземпляра MariaDB. В приведенном выше node1 случае он будет использовать файл параметров по пути /etc/my.cnf.d/mynode1.cnf для дистрибутивов типа RHEL и /etc/mysql/conf.d/mynode1.cnf для дистрибутивов типа Debian.

При использовании нескольких экземпляров каждый экземпляр, конечно же, также потребует собственный datadir. Обратитесь к mariadb-install-db за информацией о том, как инициализировать datadir для дополнительных экземпляров MariaDB.

Systemd и кластер Galera

Инициализация нового кластера

При использовании кластера Galera с systemd, первый узел в кластере должен быть запущен с galera_new_cluster. Для получения дополнительной информации см. Начало работы с MariaDB Galera Cluster: Инициализация нового кластера.

Восстановление позиции узла в кластере

При использовании кластера Galera с systemd, позиция узла в кластере может быть восстановлена с помощью galera_recovery. Для получения дополнительной информации см. Начало работы с MariaDB Galera Cluster: Определение самого продвинутого узла.

SST и Systemd

Файл systemd службы MariaDB имеет стандартный таймаут запуска около 90 секунд на большинстве систем. Если запуск SST занимает больше этого значения таймаута на узле-присоединителе, то systemd предположит, что mariadbd не удалось запуститься, что приводит к тому, что systemd завершает процесс mariadbd на узле-присоединителе. Чтобы обойти это, можно перенастроить единицу systemd MariaDB, задав бесконечный таймаут. Дополнительную информацию см. в разделе Введение в передачи моментальных снимков состояния (SST): SST и Systemd.

Обратите внимание, что systemd 236 добавили переменную среды EXTEND_TIMEOUT_USEC, которая позволяет службам продлевать таймаут запуска во время длительных процессов. Начиная с MariaDB 10.1.35, MariaDB 10.2.17 и MariaDB 10.3.8, на системах с версиями systemd, которые поддерживают эту функцию, MariaDB использует её для продления таймаута запуска во время длительных SST. Поэтому, если вы используете systemd 236 или более позднюю версию, вам не нужно вручную переопределять TimeoutStartSec, даже если ваши SST выполняются дольше, чем заданное значение. Дополнительную информацию см. в разделе MDEV-15607.

Настройка службы Systemd

Вы можете настроить службу systemd MariaDB, создав файл конфигурации «drop-in» для службы systemd. На большинстве систем директория для файлов конфигурации «drop-in» службы systemd имеет значение /etc/systemd/system/mariadb.service.d/. Вы можете проверить директорию и посмотреть, какие файлы конфигурации «drop-in» загружены в данный момент, выполнив:

$ sudo systemctl status mariadb.service
● mariadb.service - MariaDB 10.1.37 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf, timeoutstartsec.conf
...

Если вы хотите настроить службу systemd, то можете создать файл с расширением .conf в этой директории. Необходимые параметры конфигурации должны быть размещены в соответствующем разделе файла, обычно в разделе [Service]. Если параметр systemd представляет собой список, то возможно, потребуется установить значение параметра на пустое значение перед установкой новых значений. Например:

[Service]

ExecStart=
ExecStart=/usr/bin/numactl --interleave=all  /usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION

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

sudo systemctl daemon-reload

Полезные параметры Systemd

Полезные параметры systemd перечислены ниже. Если параметр эквивалентен обычному параметру mysqld_safe, то он также указан. Используйте systemctl edit mariadb.service для создания параметра systemd в заголовке раздела [Service].

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

Существует и другие параметры, и скрипт mariadb-service-convert попытается преобразовать их как можно точнее.

Настройка таймаута службы Systemd

Файл systemd службы MariaDB имеет стандартный таймаут запуска около 90 секунд на большинстве систем. Если запуск службы занимает больше этого стандартного таймаута, то systemd предположит, что mariadbd не удалось запустить, что приведет к тому, что systemd завершит процесс mariadbd. Чтобы обойти это, можно изменить этот параметр, настроив параметр TimeoutStartSec для службы systemd. Аналогичная проблема может возникнуть при остановке службы MariaDB. Поэтому, возможно, стоит также установить TimeoutStopSec.

Например, можно перенастроить службу systemd MariaDB, задав бесконечный таймаут, выполнив одну из следующих команд:

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

sudo systemctl edit mariadb.service

[Service]

TimeoutStartSec=0
TimeoutStopSec=0

Systemd 229 добавили параметр infinity, поэтому, если вы используете systemd 229 или более позднюю версию, то выполните следующее для установки бесконечного таймаута:

sudo systemctl edit mariadb.service

[Service]

TimeoutStartSec=infinity
TimeoutStopSec=infinity

Обратите внимание, что systemd 236 добавили переменную среды EXTEND_TIMEOUT_USEC, которая позволяет службам продлевать таймаут запуска во время длительных процессов. На системах с системами systemd, которые поддерживают эту функцию, MariaDB использует её для продления таймаута запуска во время определённых процессов запуска, которые могут быть длительными.

Настройка предела на количество открытых файлов

При использовании systemd, вместо установки предела на открытые файлы путём настройки параметра open-files-limit для mysqld_safe или системной переменной open_files_limit, предел может быть изменён путём настройки параметра LimitNOFILE для службы MariaDB systemd. По умолчанию он установлен в LimitNOFILE=16364 в mariadb.service.

Например, можно перенастроить службу systemd MariaDB, установив более высокое значение предела на количество открытых файлов, выполнив следующие команды:

sudo systemctl edit mariadb.service

[Service]

LimitNOFILE=infinity

Важно отметить, что установка LimitNOFILE=infinity фактически не устанавливает предел на открытые файлы в бесконечность.

В systemd 234 и более поздних версиях, установка LimitNOFILE=infinity фактически устанавливает предел открытых файлов в значение параметра ядра fs.nr_open. Поэтому в этих версиях systemd вам может потребоваться изменить значение этого параметра.

Значение параметра fs.nr_open можно изменить постоянно, установив значение в /etc/sysctl.conf и перезапустив сервер.

Значение параметра fs.nr_open можно изменить временно, выполнив утилиту sysctl.

sudo sysctl -w fs.nr_open=1048576‬

В systemd 233 и более ранних версиях, установка LimitNOFILE=infinity фактически устанавливает предел открытых файлов в 65536. См. проблему systemd #6559 для получения дополнительной информации. Поэтому в этих версиях systemd рекомендуется установить LimitNOFILE=infinity в очень большое целое число. Например:

sudo systemctl edit mariadb.service

[Service]
LimitNOFILE=1048576

Настройка размера файла ядра

При использовании systemd, если вы хотите включить вывод core дампов, вместо установки размера файла ядра путём настройки параметра core-file-size для mysqld_safe, предел можно изменить, настроив параметр LimitCORE для службы MariaDB systemd. Например, можно перенастроить службу systemd MariaDB, установив бесконечный размер для файлов ядра, выполнив следующие команды:

sudo systemctl edit mariadb.service

[Service]
LimitCORE=infinity

Настройка записи журнала ошибок MariaDB в Syslog

При использовании systemd, если требуется перенаправить журнал ошибок в syslog, это можно легко сделать следующим образом:

• Убедитесь, что системная переменная log_error не установлена.
• Установите StandardOutput=syslog.
• Установите StandardError=syslog.
• Установите SyslogFacility=daemon.
• Установите SysLogLevel=err.

Например:

sudo systemctl edit mariadb.service

[Service]

StandardOutput=syslog
StandardError=syslog
SyslogFacility=daemon
SysLogLevel=err

Если у вас несколько экземпляров MariaDB, то также можно установить SyslogIdentifier с разными метками для каждого экземпляра.

Настройка LimitMEMLOCK

При использовании --memlock или iouring в InnoDB в MariaDB 10.6 с версией ядра Linux < 5.12, необходимо увеличить ограничение LimitMEMLOCK.

sudo systemctl edit mariadb.service

[Service]

LimitMEMLOCK=2M

Примечание: До MariaDB 10.1.10 параметр --memlock нельзя было использовать с сервисом MariaDB systemd.

Настройка доступа к домашним каталогам

Файл unit-сервиса MariaDB systemd по умолчанию ограничивает доступ к /home, /root, и /run/user. Это ограничение можно обойти, установив параметр ProtectHome в значение false для сервиса MariaDB systemd. Это делается путём создания каталога "drop-in" /etc/systemd/system/mariadb.service.d/ и размещения в нём файла с суффиксом .conf, содержащего директиву ProtectHome=false.

Вы можете перенастроить сервис MariaDB systemd для разрешения доступа к /home выполнив следующие команды:

sudo systemctl edit mariadb.service

[Service]

ProtectHome=false

Настройка umask

При использовании systemd, значения по умолчанию для прав доступа к mariadbd могут быть установлены с помощью переменных окружения UMASK и UMASK_DIR для сервиса systemd. Например, вы можете настроить umask для сервиса MariaDB systemd выполнив следующие команды:

sudo systemctl edit mariadb.service

[Service]

Environment="UMASK=0750"
Environment="UMASK_DIR=0750"

Для получения дополнительной информации см. Указание прав доступа для каталогов схемы (данных) и таблиц.

Настройка каталога данных

При стандартной установке из бинарного архива, каталог данных будет находиться в /usr/local/data. Однако, по умолчанию, файл сервиса systemd защищает от записи весь древовидный каталог /usr.

Поэтому при простом копировании файла сервиса из архива, установка из tarball не начнется, например, с сообщением об ошибке:

[Warning] Can't create test file /usr/local/.../data/ubuntu-focal.lower-test
[ERROR] mariadbd: File '/usr/local/.../data/aria_log_control' not found (Errcode: 30 "Read-only file system")
[ERROR] mariadbd: Got error 'Can't open file' when trying to use aria control file '/usr/local/.../data/aria_log_control'

Поэтому, при использовании каталога данных в /usr/local, необходимо сделать этот каталог доступным для записи сервису с помощью параметра ReadWritePaths:

sudo systemctl edit mariadb.service

[Service]
ReadWritePaths=/usr/local/mysql/data

Активация сокета systemd

Это служба по запросу для MariaDB, которая активируется при необходимости.

Активация сокета systemd использует файл определения mariadb.socket, чтобы определить набор сокетов UNIX и TCP. Systemd будет прослушивать эти сокеты, и при подключении к ним systemd запустит mariadb.service и передаст дескрипторы сокетов MariaDB для обработки соединения.

MariaDB продолжает работать в этот момент и имеет доступ ко всем сокетам и обрабатывает соединения точно так же, как и до версии 10.6.

Когда MariaDB остановлен, systemd mariadb.socket остается активным, и новое подключение запустит mariadb.service.

Использование активации сокета systemd

Для использования активации сокета systemd MariaDB, вместо включения/запуска mariadb.service, используется mariadb.socket.

Следовательно, следующие команды работают так же, как и mariadb.service эквиваленты.

systemctl start mariadb.socket
systemctl enable mariadb.socket

Эти файлы содержат только информацию о сокетах UNIX и TCP и основные сетевые подключения, на которые будет происходить прослушивание подключений. @mariadb - это абстрактный сокет UNIX, который не отображается в файловой системе. Клиенты, основанные на MariaDB Connector/C, смогут подключаться к ним, используя имя сокета непосредственно, при условии, что реализация на более высоком уровне не пытается проверить сначала существование файла. Некоторые коннекторы, такие как PHP, используют mysqlnd, который является чисто PHP-реализацией, и поэтому смогут подключаться только к сокетам UNIX в файловой системе.

При использовании сокетов systemd ограничение на количество сокетов, к которым можно подключиться, определяется только лимитом на дескрипторы файлов.

Когда использовать активацию сокета systemd

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

Идеальный случай использования активации сокета systemd для MariaDB – для провайдеров инфраструктуры, работающих с несколькими экземплярами MariaDB, где каждый экземпляр выделен для определенного пользователя.

Недостатки использования активации сокета systemd

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

Настройка активации сокета systemd

Когда MariaDB работает с активацией сокета systemd, обычные системные переменные socket, port и backlog игнорируются, так как эти настройки содержатся в файле определения сокета systemd.

Для использования MariaDB с активацией сокета не требуется никаких настроек в самом MariaDB.

Доступные параметры systemd взяты из systemd documentation, но ListenStream и BackLog являются наиболее распространёнными параметрами конфигурации.

Поскольку MariaDB не создаёт эти сокеты, сокеты не нужно создавать с пользователем mysql. Возможно, у MariaDB не было привилегий для создания сокетов, которые он может прослушивать при использовании активации сокета systemd.

Изменения в стандартных значениях mariadb.socket могут быть внесены таким же образом, как и для сервисов, systemctl edit mariadb.socket, или используя файлы /etc/systemd/system/mariadb.socket.d/someconfig.conf.

Дополнительный порт

Сокет systemd может быть настроен как extra_port, by using the FileDescriptorName=extra in the .socket file.

mariadb-extra.socket уже упаковано и готово к использованию.

Активация сокета для нескольких экземпляров

mariadb@.socket - это упакованное определение MariaDB для нескольких экземпляров. Оно создаёт несколько сокетов UNIX, основанных на стартовом файле сокета.

Запуск mariadb@bob.socket будет использовать определение mariadb@.socket с %I в определении, заменённым на "bob".

Когда к определенному сокету происходит подключение, запускается mariadb@bob.service.

Активация сокета systemd для провайдеров хостинговых услуг

Служба активации сокета systemd с несколькими экземплярами может обеспечить по требованию доступ для каждого пользователя к выделенной базе данных провайдера хостинговых услуг.

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

Преимущества для конечного пользователя

Это предоставляет следующие преимущества для пользователя:

• Каждый пользователь имеет свой собственный выделенный экземпляр со следующими преимуществами:
  • Экземпляр свободен от конкуренции за базу данных со стороны соседей по общим ресурсам MariaDB (кеш таблиц, подключения и т. д.)
  • Пользователь свободен изменять собственную конфигурацию MariaDB в рамках ограничений и разрешений провайдера услуг.
  • Резервное копирование базы данных, например, mariabackup, теперь доступны напрямую.
  • Пользователь может устанавливать собственные плагины.
  • Пользователь может использовать другую версию базы данных, отличную от своих соседей.
  • Если сосед пользователя вызывает сбой на сервере, экземпляр пользователя не затронут.
• База данных работает как пользователь UNIX на сервере, что облегчает:
  • Пользователь может напрямую мигрировать свой каталог данных MariaDB к другому провайдеру.
  • Данные пользователя защищены от других пользователей на уровне ядра.

Преимущества для провайдера хостинговых услуг

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

• Отсутствие паролей для базы данных при сохранении безопасности, что может упростить поддержку.
• Когда база данных пользователя неактивна, нет использования ресурсов, только дескрипторы файлов, прослушиваемые systemd.
• Активация сокета прозрачно и с небольшим временем запуска запускает службу по требованию.
• Когда база данных пользователя неактивна в течение некоторого времени, она деактивируется (MDEV-25282).
• Планируемые усовершенствования InnoDB обеспечивают:
  • потребительское потребление памяти (MDEV-25340).
  • проактивное уменьшение использования памяти (MDEV-25341).
  • снижение нагрузки на ресурсы памяти (MDEV-24670).
• Провайдер услуг по-прежнему может ограничивать использование памяти базы данных пользователя в способе ulimit, который пользователь не может изменить в настройках.
• Провайдер услуг может выбрать оплату пользователю на основе использования ЦП/памяти/ВВОД/ВЫВОД с помощью учёта cgroup в Linux, а не на основе доступности, по сравнению с довольно ограниченными вариантами в CREATE USER.
• Поскольку база данных пользователя будет выключена при отсутствии активности, обновление базы данных на сервере не повлияет на пользователя, пока он пассивно не остановится, перезапустится и не активируется повторно, что сокращает время простоя пользователя.

Недостатки провайдера хостинг-услуг

Дополнительная память, используемая большее количеством экземпляров. Это смягчается благодаря активации по требованию. Деактивация при бездействии и улучшенное управление памятью InnoDB.

При большом количестве работающих серверов баз данных среднего размера, утилита Linux OOM kill может убить лишь небольшое число работающих серверов баз данных, а не все.

Пример элементов конфигурации для многоэкземплярной службы с активацией сокета systemd на пользователя

С точки зрения сервера операция будет следующей;

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

# systemctl start mariadb@username.socket
# systemctl start mariadb-extra@username.socket

Для активации этой функции при перезагрузке (так же, как и для службы systemd):

# systemctl enable mariadb@username.socket
# systemctl enable mariadb-extra@username.socket

Файл шаблона MariaDB

Глобальный файл шаблона. После установки в качестве файла пользователя $HOME/.my.cnf, он станет значением по умолчанию для многих приложений и самого сервера MariaDB.

# cat /etc/my.cnf.templ
[client]
socket=/home/USER/mariadb.sock

[client-server]
user=USER

[mariadbd]
datadir=/home/USER/mariadb-datadir

Настройка многоэкземплярной службы

Это расширение/модификация службы MariaDB с множеством экземпляров.

Функции этого расширения:

• автоматическое создание файла конфигурации для приложений пользователя
• Установка базы данных при первом запуске службы
• auth-root-* в mariadb-install-db означает, что пользователь является собственным привилегированным пользователем с активной аутентификацией через сокет Unix. Это означает, что другой пользователь не может получить доступ к службе другого пользователя, даже с доступом к сокетам Unix. Дополнительную информацию см. в безопасности аутентификации через сокет Unix.
• При обновлении версии MariaDB изменения обновления применяются автоматически
• LimitData устанавливает жесткий верхний предел, чтобы пользователь не превысил определенную долю ресурсов сервера

# cat /etc/systemd/system/mariadb@.service.d/user.conf
[Service]
User=%I
ProtectHome=false

Environment=MYSQLD_MULTI_INSTANCE="--defaults-file=/home/%I/.my.cnf"

ExecStartPre=
ExecStartPre=/bin/sh -c "[ -f /home/%I/.my.cnf ] || sed -e \"s/USER/%I/g\" /etc/my.cnf.templ > /home/%I/.my.cnf"
ExecStartPre=mkdir -p /home/%I/mariadb-datadir
ExecStartPre=/usr/bin/mariadb-install-db $MYSQLD_MULTI_INSTANCE --rpm \
   --auth-root-authentication-method=socket --auth-root-socket-user=%I
ExecStartPost=/usr/bin/mariadb-upgrade $MYSQLD_MULTI_INSTANCE

# To limit user based tuning
LimitData=768M
# For io_uring use by innodb on < 5.12 kernels
LimitMEMLOCK=1M

Настройка многоэкземплярного сокета

Это расширение/модификация определения сокета MariaDB для каждого пользователя.

Создание сокетов на основе пользователя экземпляра (%I). Разрешения необходимы только в том смысле, что пользователь может подключаться к ним. Это не повлияет на сервер. Контроль доступа выполняется внутри сервера, однако, если пользовательские веб-сервисы выполняются как пользователь, Mode=777 может быть уменьшен. @mariadb-%I — это абстрактный сокет Unix, а не в файловой системе. Это может быть полезно, если пользователь находится в chroot. Не все приложения могут подключаться к абстрактным сокетам.

# cat /etc/systemd/system/mariadb@.socket.d/user.conf
[Socket]
SocketUser=%I
SocketMode=777
ListenSteam=
ListenStream=@mariadb-%I
ListenStream=/home/%I/mariadb.sock

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

# cat /etc/systemd/system/mariadb-extra@.socket.d/user.conf
[Socket]
SocketUser=%I
SocketMode=777
ListenSteam=
ListenStream=@mariadb-extra-%I
ListenStream=/home/%I/mariadb-extra.sock

Журнал Systemd

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

Журнал службы MariaDB systemd можно запросить с помощью команды journalctl. Например:

$ sudo journalctl n 20 -u mariadb.service
-- Logs begin at Fri 2019-01-25 13:49:04 EST, end at Fri 2019-01-25 18:07:02 EST. --
Jan 25 13:49:15 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: Starting MariaDB 10.1.37 database server...
Jan 25 13:49:16 ip-172-30-0-249.us-west-2.compute.internal mysqld[2364]: 2019-01-25 13:49:16 140547528317120 [Note] /usr/sbin/mysqld (mysqld 10.1.37-MariaDB) starting as process 2364 ...
Jan 25 13:49:17 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: Started MariaDB 10.1.37 database server.
Jan 25 18:06:42 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: Stopping MariaDB 10.1.37 database server...
Jan 25 18:06:44 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: Stopped MariaDB 10.1.37 database server.
Jan 25 18:06:57 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: Starting MariaDB 10.1.37 database server...
Jan 25 18:08:32 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: mariadb.service start-pre operation timed out. Terminating.
Jan 25 18:08:32 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: Failed to start MariaDB 10.1.37 database server.
Jan 25 18:08:32 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: Unit mariadb.service entered failed state.
Jan 25 18:08:32 ip-172-30-0-249.us-west-2.compute.internal systemd[1]: mariadb.service failed.

Преобразование параметров mysqld_safe в параметры Systemd

mariadb-service-convert — это скрипт, включенный во многие пакеты MariaDB, который используется менеджером пакетов для преобразования mysqld_safe параметров в systemd параметры. Он считывает все явные настройки в [mysqld_safe] группе параметров из файлов параметров, а его вывод направляется в /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf. Это помогает сохранить конфигурацию неизменной при обновлении с версии MariaDB, не использующей systemd, до версии, которая это делает.

Неявные высокие значения по умолчанию для open-files-limit могут быть пропущены скриптом преобразования и требуют явной настройки. См. Настройка лимита открытых файлов.