close
  • chevron_right

    MySQL vs MariaDB: What Are the Main Differences Between Them (MariaDB is actually forked from MySQL)

    Danie van der Merwe · news.movim.eu / gadgeteerza-tech-blog · Wednesday, 6 October - 14:15

MySQL and MariaDB are relational database management systems (RDBMS) best known for their mutual compatibility and their identical command and query syntaxes. In fact, MariaDB is a free and open source fork of MySQL that inherited many of that database’s characteristics.

The MariaDB and MySQL database management systems have a lot in common, which can make it difficult to choose when you need to decide on a database solution for your needs.

An in-depth comparison of MariaDB vs MySQL based on license model, popularity, features, performance, and support.

See https://linuxiac.com/mysql-vs-mariadb/

#technology #databases #opensource #MySQL #MariaDB

  • In chevron_right

    Oracle accelerates MySQL HeatWave queries with machine learning

    pubsub.slavino.sk / infoworldcom · Tuesday, 10 August - 19:18 edit

Taking aim at competitors including Amazon Aurora and Snowflake , Oracle has enhanced the MySQL HeatWave in-memory query accelerator in the Oracle Cloud’s MySQL Database Service by leveraging advanced machine learning. But Oracle insists the improvements do not mean the MySQL Database Service is encroaching on its flagship Oracle Database .

To read this article in full, please click here


Značky: #Database, #Rozne, #MySQL

  • chevron_right

    13 Tips for Tuning and Optimizing MySQL and MariaDB Databases

    Danie van der Merwe · news.movim.eu / gadgeteerza-tech-blog · Thursday, 5 August - 09:04

MySQL and MariaDB are the most widely used relational database management systems (RDMS) when it comes to website hosting and CMS systems such as Joomla, WordPress, Drupal, and Typo 3. In this article, I will explain how to speed up and optimize your MySQL and MariaDB database server.

Probably not much need to worry about this is you just have a single WordPress instance, but if you're running a few different services all using a MySQL database and quite a few users, it may be well worth looking into to tweak performance a bit. Just always make sure you've done backups before making changes.

See https://vitux.com/tune-and-optimize-mysql-mariadb/

#technology #databases #MySQL #MariaDB

  • chevron_right

    MySQL 101: Installation, care, and feeding on Ubuntu

    news.movim.eu / ArsTechnica · Friday, 11 June - 19:23

Warning: Learning the care and feeding of MySQL instances does not grant knowledge of or safe interaction with actual marine mammals.

Enlarge / Warning: Learning the care and feeding of MySQL instances does not grant knowledge of or safe interaction with actual marine mammals. (credit: Oracle)

One of the tasks nearly any sysadmin frequently encounters is the care and feeding of the MySQL database server. You can build an entire career around nothing but this topic—making you a DB admin, not a humble sysadmin like yours truly—but for today, we're just going to cover the basics.

For this guide, we're going to be using Ubuntu Linux as the underlying operating system—but most of these steps and tips will be either the same, or broadly similar, across nearly any OS or distribution you might install MySQL on.

Installing MySQL

Installing MySQL on a fresh Ubuntu instance is quite simple: sudo apt update if necessary, then sudo apt install mysql-server and you're off to the races. Once the package is downloaded and installed, mysql is fired up automatically (and will be after each system reboot).

Read 55 remaining paragraphs | Comments

index?i=cyRND7I5040:t3502yLowmY:V_sGLiPBpWUindex?i=cyRND7I5040:t3502yLowmY:F7zBnMyn0Loindex?d=qj6IDK7rITsindex?d=yIl2AUoC8zA
  • Sy chevron_right

    История и тенденции Zabbix в TokuDB

    pubsub.slavino.sk / sysadmblog · Sunday, 16 August, 2020 - 08:00 edit · 6 minutes

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

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

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

В случае с MySQL первым делом нужно убедиться, что база данных не находится в одном файле и, при необходимости, разнести таблицы по разным файлам: сделать полную резервную копию, удалить базы данных, включить innodb_file_per_table=YES, перезапустить MySQL, восстановить базы данных из резервных копий.

Другой важный шаг: нужно убедиться, что основной буфер СУБД, размер которого настраивается через innodb_buffer_pool_size, имеет максимально доступный объём. Чем больше объём этого буфера, тем больше «горячих», часто требуемых данных, может в нём уместиться. Идеально, если вся СУБД умещается в оперативной памяти целиком. На практике, однако, это редко достижимо, т.к. таблицы истории и тенденций в базе данных Zabbix могут достигать сотен гигабайт. В любом случае, если есть возможность, лучше увеличить объём оперативной памяти на сервере с СУБД.

Также стоит обратить внимание на размеры журналов innodb_log_file_size: Zabbix пишет много данных и размер этих файлов должен соответствовать объёму данных, которые записываются системой в секунду (лимит для этой опции - 2 гигабайта). Оборотной стороной больших журналов является более длительный запуск сервера MySQL.

Когда выполнены предыдущие рекомендации - на контроле есть только самое необходимое, данные снимаются с разумными интервалами времени, произведена оптимизация настроек - следующим этапом обычно идёт отключение HouseKeeper'а и секционирование таблиц истории и тенденций. Понять, о том что настало время отключать HouseKeeper, можно обратившись ко внутреннему мониторингу Zabbix. Если на графиках процесс HouseKeeper почти постоянно используется на 100%, а увеличение настроек HouseKeepingFrequency и HouseKeeperDelete не приводят к желаемому эффекту, значит пора. Zabbix не имеет официальной поддержки секционирования таблиц, однако можно найти готовые инструкции для его настройки.

Ранее я использовал для разбивки таблиц на секции вот эту статью на wiki-странице Zabbix: Docs/howto/mysql partitioning , однако впоследствии стал пользоваться вот этой статьёй: Docs/howto/mysql partition . У второй статьи есть два преимущества:
  1. при её использовании в базе данных Zabbix не нужно создавать дополнительную нестандартную таблицу manage_partitions,
  2. при её использовании имеется возможность делить таблицы не только на секции месячного или суточного размера, но и на секции произвольного размера, в том числе более мелкого.
Наконец, в интернете можно встретить советы по смене движка таблиц истории и тенденций с родного для MySQL движка InnoDB на движок TokuDB с технологией «фрактальных индексов». Также вместе с этим движком рекомендуют использовать «кластерные индексы», когда индексы хранятся вместе с данными, и сжатие данных в таблицах.

Изначально TokuDB был ответвлением MySQL, в котором фирма Tokutek реализовала собственную технологию «фрактальных индексов». Позже исходные тексты TokuDB стали доступны под свободной лицензией и на их основе был реализован плагин, пригодный подключению как к оригинальной СУБД MySQL, так и к её ответвлениям - MariaDB и Percona.

Включение плагина TokuDB в MariaDB

Мне удавалось успешно настраивать TokuDB на Debian Stretch и Debian Buster. Установку и настройку MariaDB оставим за скобками нашего обсуждения. Будем считать, что система мониторинга уже развёрнута и использует MariaDB, а таблицы истории и тенденций пока что хранятся в таблицах формата InnoDB.

Первым делом установим пакет с плагином, который добавляет в MariaDB поддержку формата хранения таблиц TokuDB:
# apt-get install mariadb-plugin-tokudb
Вместе с пакетом будет установлен дополнительный файл конфигурации /etc/mysql/mariadb.conf.d/tokudb.cnf, в котором указан путь к библиотеке libjemalloc. В случае с Debian Stretch это будет путь /usr/lib/x86_64-linux-gnu/libjemalloc.so.1 В случае с Debian Buster это будет путь /usr/lib/x86_64-linux-gnu/libjemalloc.so.2 Прежде чем продолжать, стоит удостовериться, что этот файл действительно сущетсвует в системе, т.к. при обновлении операционной системы до свежего релиза в файле конфигурации мог остаться устаревший путь. В Debian Stretch этот файл устанавливается с пакетом libjemalloc1, а в Debian Buster - пакетом libjemalloc2. Необходимо установить соответствующий пакет и исправить путь к файлу в файле конфигурации.

Теперь нужно убедиться, что в системе отключена прозрачная поддержка огромных страниц (Transparent Hugepages). Для этого запускаем следующую команду:
$ cat /sys/kernel/mm/transparent_hugepage/enabled
Если команда поругалась на отсутствие файла, значит прозрачная поддержка огромных страниц уже отключена и делать больше ничего не нужно. Также ничего не нужно делать, если команда вывела следующее:
always madvise [never]
Если же команда вывела приведённый ниже текст, то прозрачная поддержка огромных страниц включена и её необходимо отключить:
[always] madvise never
Открываем файл /etc/default/grub, находим переменную GRUB_CMDLINE_LINUX и добавляем в список опций опцию transparent_hugepage=never. В результате должно получиться что-то такое:
GRUB_CMDLINE_LINUX="ipv6.disable=1 transparent_hugepage=never"
Теперь нужно обновить конфигурацию загрузчика следующей командой:
# update-grub
Осталось перезагрузить систему и убедиться в том, что прозрачная поддержка огромных страниц действительно отключилась.

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

Создание новых таблиц истории и тенденций

Если база данных только создана и не содержит исторических данных и данных тенденций, то можно просто удалить существующие таблицы:
DROP TABLE history;
DROP TABLE history_uint;
DROP TABLE history_str;
DROP TABLE history_log;
DROP TABLE history_text;
DROP TABLE trends;
DROP TABLE trends_uint;
Если же нужно выполнить миграцию существующей инсталляции Zabbix, тогда лучше сначала переименовать существующие таблицы истории и тенденций:
RENAME TABLE history TO history_bak;
RENAME TABLE history_uint TO history_uint_bak;
RENAME TABLE history_str TO history_str_bak;
RENAME TABLE history_log TO history_log_bak;
RENAME TABLE history_text TO history_text_bak;
RENAME TABLE trends TO trends_bak;
RENAME TABLE trends_uint TO trends_uint_bak;
Вместо прежних таблиц нужно будет создать новые пустые таблицы истории и тенденций, сначала без разбивки на секции, с помощью следующих SQL-запросов:
CREATE TABLE `history` (
`itemid` bigint unsigned NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`value` double(16,4) DEFAULT '0.0000' NOT NULL,
`ns` integer DEFAULT '0' NOT NULL
) ENGINE=TokuDB COMPRESSION=TOKUDB_LZMA;
CREATE INDEX `history_1` ON `history` (`itemid`,`clock`) CLUSTERING=yes;

CREATE TABLE `history_uint` (
`itemid` bigint unsigned NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`value` bigint unsigned DEFAULT '0' NOT NULL,
`ns` integer DEFAULT '0' NOT NULL
) ENGINE=TokuDB COMPRESSION=TOKUDB_LZMA;
CREATE INDEX `history_uint_1` ON `history_uint` (`itemid`,`clock`) CLUSTERING=yes;

CREATE TABLE `history_str` (
`itemid` bigint unsigned NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`value` varchar(255) DEFAULT '' NOT NULL,
`ns` integer DEFAULT '0' NOT NULL
) ENGINE=TokuDB COMPRESSION=TOKUDB_LZMA;
CREATE INDEX `history_str_1` ON `history_str` (`itemid`,`clock`) CLUSTERING=yes;

CREATE TABLE `history_log` (
`itemid` bigint unsigned NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`timestamp` integer DEFAULT '0' NOT NULL,
`source` varchar(64) DEFAULT '' NOT NULL,
`severity` integer DEFAULT '0' NOT NULL,
`value` text NOT NULL,
`logeventid` integer DEFAULT '0' NOT NULL,
`ns` integer DEFAULT '0' NOT NULL
) ENGINE=TokuDB COMPRESSION=TOKUDB_LZMA;
CREATE INDEX `history_log_1` ON `history_log` (`itemid`,`clock`) CLUSTERING=yes;

CREATE TABLE `history_text` (
`itemid` bigint unsigned NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`value` text NOT NULL,
`ns` integer DEFAULT '0' NOT NULL
) ENGINE=TokuDB COMPRESSION=TOKUDB_LZMA;
CREATE INDEX `history_text_1` ON `history_text` (`itemid`,`clock`) CLUSTERING=yes;

CREATE TABLE `trends` (
`itemid` bigint unsigned NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`num` integer DEFAULT '0' NOT NULL,
`value_min` double(16,4) DEFAULT '0.0000' NOT NULL,
`value_avg` double(16,4) DEFAULT '0.0000' NOT NULL,
`value_max` double(16,4) DEFAULT '0.0000' NOT NULL,
PRIMARY KEY (itemid,clock) CLUSTERING=yes
) ENGINE=TokuDB COMPRESSION=TOKUDB_LZMA;

CREATE TABLE `trends_uint` (
`itemid` bigint unsigned NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`num` integer DEFAULT '0' NOT NULL,
`value_min` bigint unsigned DEFAULT '0' NOT NULL,
`value_avg` bigint unsigned DEFAULT '0' NOT NULL,
`value_max` bigint unsigned DEFAULT '0' NOT NULL,
PRIMARY KEY (itemid,clock) CLUSTERING=yes
) ENGINE=TokuDB COMPRESSION=TOKUDB_LZMA;
Эти таблицы пока не разбиты на секции, но уже используют движок TokuDB, сжатие данных по алгоритму LZMA и используют кластерные индексы - индексы, хранящиеся вместе с индексируемыми данными.

Разбивка таблиц на секции

Разбивку таблиц на секции я проводил в соответствии со статьёй Docs/howto/mysql partition .

Я подготовил скрипт, который выводит команды, необходимые для разбивки таблиц истории и тенденций на необходимые секции. Настройки начальной и конечной дат, а также размер каждой секции, задаются прямо в тексте скрипта:
#!/usr/bin/python
# -*- coding: UTF-8 -*-

from datetime import datetime, timedelta
from pytz import timezone

def table_partitions(table, start, stop, step):
print 'ALTER TABLE `%s` PARTITION BY RANGE (`clock`) (' % table

dt = start
while dt < stop:
name = dt.strftime('%Y%m%d%H%M')
ts = dt.strftime('%s')
dt += step
print 'PARTITION p%s VALUES LESS THAN (%s) ENGINE = TokuDB,' % (name, ts)

name = dt.strftime('%Y%m%d%H%M')
ts = dt.strftime('%s')
print 'PARTITION p%s VALUES LESS THAN (%s) ENGINE = TokuDB' % (name, ts)
print ');'

tz = timezone('UTC')
# Для таблиц тенденций trends и trends_uint
start = datetime(2018, 9, 10, 0, 0, 0, tzinfo=tz)
stop = datetime(2019, 9, 22, 0, 0, 0, tzinfo=tz)
step = timedelta(days=1)
table_partitions('trends', start, stop, step)
table_partitions('trends_uint', start, stop, step)

# Для таблиц истории history и history_uint
start = datetime(2019, 6, 10, 0, 0, 0, tzinfo=tz)
stop = datetime(2019, 9, 22, 0, 0, 0, tzinfo=tz)
step = timedelta(hours=6)
table_partitions('history', start, stop, step)
table_partitions('history_uint', start, stop, step)

# Для таблиц истории history_str, history_text и history_log
start = datetime(2019, 9, 3, 0, 0, 0, tzinfo=tz)
stop = datetime(2019, 9, 22, 0, 0, 0, tzinfo=tz)
step = timedelta(days=1)
table_partitions('history_str', start, stop, step)
table_partitions('history_text', start, stop, step)
table_partitions('history_log', start, stop, step)
Запускаем скрипт, сохраняем выведенные им команды в файл:
$ ./partitions.py > partitions.sql
Затем подключаемся клиентом MySQL к базе данных zabbix:
$ mysql -uzabbix -p zabbix
И выполняем в нём команды из файла partitions.sql:
MariaDB [zabbix]> SOURCE partitions.sql
После выполнения команд таблицы будут разбиты на секции в соответствии с настройками, прописанными в скрипте partitions.py

Перенос имеющихся данных в новые таблицы

Можно было бы перенести данные из старых таблиц в новые простыми SQL-запросами вида INSERT INTO history_uint SELECT * FROM history_uint_bak, но такие запросы на время их работы будут полностью блокировать вставку новых данных в таблицу, поэтому надо переносить данные порциями. Я в этих целях пользуюсь командами следующего вида:
$ mysqldump -t -uroot -p zabbix trends_uint_bak | grep ^INSERT | sed 's/^INSERT INTO/INSERT IGNORE/g' | mysql -uroot -p zabbix
$ mysqldump -t -uroot -p zabbix trends_bak | grep ^INSERT | sed 's/^INSERT INTO/INSERT IGNORE/g' | mysql -uroot -p zabbix
$ mysqldump -t -uroot -p zabbix history_bak | grep ^INSERT | sed 's/^INSERT INTO/INSERT IGNORE/g' | mysql -uroot -p zabbix
$ mysqldump -t -uroot -p zabbix history_str_bak | grep ^INSERT | sed 's/^INSERT INTO/INSERT IGNORE/g' | mysql -uroot -p zabbix
$ mysqldump -t -uroot -p zabbix history_text_bak | grep ^INSERT | sed 's/^INSERT INTO/INSERT IGNORE/g' | mysql -uroot -p zabbix
$ mysqldump -t -uroot -p zabbix history_log_bak | grep ^INSERT | sed 's/^INSERT INTO/INSERT IGNORE/g' | mysql -uroot -p zabbix
Это не красивое решение, но оно меня вполне устраивает, т.к. не приводит к длительной блокировке таблиц.

После переноса данных в новые таблицы старые таблицы можно будет удалить:
DROP TABLE history_bak;
DROP TABLE history_uint_bak;
DROP TABLE history_str_bak;
DROP TABLE history_log_bak;
DROP TABLE history_text_bak;
DROP TABLE trends_bak;
DROP TABLE trends_uint_bak;

Настройки плагина TokuDB

Просмотрев видеоролик с выступлением Владислава Лесина - одного из нынешних разработчиков TokuDB, работающего над этим плагином в компании Percona - я составил для себя список настроек плагина, на которые следует обратить внимание:

tokudb_fanout - максимальное количество дочерних узлов

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

tokudb_block_size - размер узла в памяти

По умолчанию - 4 мегабайта.

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

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

tokudb_read_block_size - размер базового узла

По умолчанию - 64 килобайта.

Меньшие значения лучше для точечных чтений, но приводят к увеличению непоследовательных операций ввода-вывода.

tokudb_row_format - алгоритм сжатия колонок

Возможны следующие значения:
  • tokudb_default, tokudb_zlib - среднее сжатие при средней нагрузке на процессор.
  • tokudb_snappy - хорошее сжатие при низкой нагрузке на процессор.
  • tokudb_fast, tokudb_quicklz - слабое сжатие при низкой нагрузке на процессор.
  • tokudb_small, tokudb_lzma - лучшее сжатие при высокой нагрузке на процессор.
  • tokudb_uncompressed - сжатие не используется.

tokudb_directio - использование прямого ввода-вывода

Значение OFF позволяет использовать дисковый кэш операционной системы в качестве вторичного кэша для хранения сжатых узлов. Для ограничения использования памяти процессом mysqld нужно использовать cgroups.

В качестве пищи для размышлений можно принять во внимание настройки, использованные в тесте производительности TokuDB, описание которого доступно по ссылке LinkeBench MySQL :
tokudb_cache_size = 8G ; default = 12G ?
tokudb_directio = OFF
tokudb_empty_scan = disabled ; default - rl
tokudb_read_block_size = 16K ; default - 64K
tokudb_commit_sync = ON
tokudb_checkpointing_period = 900 ; default = 60
tokudb_block_size = 4M
tokudb_cleaner_iterations = 10000 ; default = 5
tokudb_fanout = 128 ; default = 16
Я ограничился указанием подходящего значения tokudb_cache_size и изменением следующих настроек:
tokudb_directio = ON
tokudb_row_format = tokudb_lzma
tokudb_empty_scan = disabled

Решение проблем

После обновления версии MariaDB пакетами из репозитория по неизвестным причинам планировщик перестаёт выполнять задачу по обслуживанию секций таблиц: не удаляет устаревшие секции и, что гораздо хуже, не создаёт новые секции таблиц. Последнее приводит к тому, что сервер Zabbix не может вставить в таблицы новые данные. Проявляется это в том, что после полуночи в последних данных на графиках нет данных, а сервер Zabbix ругается в журнал ошибками следующего вида:
6619:20200604:000100.756 [Z3005] query failed: [1526] Table has no partition for value 1591210860 [insert into history
(itemid,clock,ns,value) values (3827556,1591210860,519948235,0.012016),(3827601,1591210860,574265420,0.016382),
(3827553,1591210860,683308669,7.549000),(3827616,1591210860,684083178,7.715000),(3827591,1591210860,684848189,3.199600),
(3827583,1591210860,685585717,0.016474),(3827504,1591210860,689418268,24.000000),(3827564,1591210860,690132132,3.209600),
(3827610,1591210860,690862622,0.014954),(1284053,1591210860,732901317,3.000000),(1283392,1591210860,737607405,23.000000),
(352809,1591210860,737607405,35.000000),(1309072,1591210860,738428022,11.000000),(3827571,1591210860,740171802,7.187000),
(1308475,1591210860,740185955,3.000000),(1292277,1591210860,743020934,1.000000),(3827619,1591210860,743278260,0.014760),
(3827573,1591210860,743976749,3.254600),(3827598,1591210860,744811430,7.577000),(1284110,1591210860,745749025,21.000000),
(3827580,1591210860,746661186,7.580000),(1279841,1591210860,747623084,5.000000),(3827607,1591210860,748043948,7.717000),
(1282792,1591210860,749216640,15.000000);
]
Если новые секции таблиц не создаются автоматически, то первым делом вручную вызываем обслуживание таблиц, чтобы сервер Zabbix мог начать писать данные:
CALL partition_maintenance('zabbix', 'trends', 365, 24, 2);
CALL partition_maintenance('zabbix', 'trends_uint', 365, 24, 2);
CALL partition_maintenance('zabbix', 'history', 90, 6, 8);
CALL partition_maintenance('zabbix', 'history_uint', 90, 6, 8);
CALL partition_maintenance('zabbix', 'history_str', 7, 24, 2);
CALL partition_maintenance('zabbix', 'history_text', 7, 24, 2);
CALL partition_maintenance('zabbix', 'history_log', 7, 24, 2);
Далее, чтобы в дальнейшем заработала автоматика, могут помочь следующие действия.

Сначала обновляем таблицы в базах данных до текущей версии MySQL:
$ mysql_upgrade --force -uroot -p mysql
$ mysql_upgrade --force -uroot -p zabbix
Затем пересоздаём запланированное задание:
USE `zabbix`;
DELIMITER $$

CREATE EVENT IF NOT EXISTS `e_part_manage`
ON SCHEDULE EVERY 1 DAY
STARTS '2019-04-04 04:00:00'
ON COMPLETION PRESERVE
ENABLE
COMMENT 'Управление созданием и удалением секций'
DO BEGIN
CALL partition_maintenance('zabbix', 'trends', 365, 24, 2);
CALL partition_maintenance('zabbix', 'trends_uint', 365, 24, 2);
CALL partition_maintenance('zabbix', 'history', 90, 6, 8);
CALL partition_maintenance('zabbix', 'history_uint', 90, 6, 8);
CALL partition_maintenance('zabbix', 'history_str', 7, 24, 2);
CALL partition_maintenance('zabbix', 'history_text', 7, 24, 2);
CALL partition_maintenance('zabbix', 'history_log', 7, 24, 2);
END$$

DELIMITER ;
И напоследок перезапускаем сервер MariaDB:
# systemctl restart mariadb
Какое из приведённых решений помогает на самом деле, сказать точно не могу, т.к. я пробовал использовать каждый из советов поодиночке и не установил чёткой закономерности, какой из них помогает всегда. Иногда одно действие не лечит проблему и на следующий день можно заметить, что новые секции опять не создались.

Značky: #linux, #stretch, #buster, #mariadb, #debian, #zabbix, #Linux, #mysql, #3.4, #tokudb

  • Sy chevron_right

    Настройка сервера MySQL

    pubsub.slavino.sk / sysadmblog · Sunday, 9 August, 2020 - 08:00 edit · 1 minute

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

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

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

expire_logs_days

Срок хранения журнала транзакций. Если данные часто и помногу обновляются, то для экономии места стоит задать значение поменьше, например 1 день:
expire_logs_days = 1
Однако, если вы используете репликацию данных на другой сервер, журналы стоит хранить за такой период времени, который может понадобиться на восстановление репликации при её поломке. В противном случае придётся повторно копировать данные с ведущего сервера на ведомый.

transaction_isolation

Уровень изоляции транзакций. Значение REPEATABLE-READ не покажет внутри транзакции новые данные, добавленные в другой транзакции. READ-COMMITED - наоборот, позволяет читать внутри транзакции данные, изменённые в других транзакциях.

Большинству приложений важна целостность и непротиворечивость данных, поэтому они используют базу данных как транзакционную (OLTP). В таком случае лучше использовать значение REPEATABLE-READ.

Если же приложение использует базу данных для аналитических запросов, то лучше подойдёт значение READ-COMMITED.

Бывают и приложения со смешанной логикой. Например, Zabbix хранит в базе данных как собственную конфигурацию, что больше соответствует OLTP, так и исторические данные со значениями определённых показателей в конкретные моменты времени, что больше соответствует OLAP. Но, т.к. нужно обеспечить непротиворечивость данных конфигурации, то запросы к таблицам истории тоже придётся выполнять на уровне изоляции транзакций REPEATABLE-READ.
transaction_isolation = REPEATABLE-READ
Для уверенности стоит поискать настройки, рекомендуемые разработчиками приложения. Если информации найти не удалось, более безопасным выбором будет REPEATABLE-READ.

innodb_file_per_table


Настройка, предписывающая хранить каждую таблицу базы данных в отдельном файле. Перед её выставлением необходимо сделать резервную копию всех баз данных. Чтобы настройка вступила в силу, нужно:
  1. остановить MySQL,
  2. удалить файлы ibdata1, ib_logfile0 и ib_logfile1,
  3. запустить MySQL снова,
  4. восстановить базы данных из резервных копий.
При восстановлении данных MySQL поместит каждую таблицу в отдельный файл.

Когда данные таблиц находятся в отдельных файлах, можно сравнительно легко вернуть в файловую систему место, освободившееся в таблице при удалении данных. Для этого достаточно запустить команду OPTIMIZE TABLE или ALTER TABLE ... FORCE над таблицей, которую нужно ужать. В случае, если используется общее хранилище для всех таблиц, неиспользуемое место никогда не возвращается на диск.

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

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

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

innodb_file_per_table = 1

table_cache

Количество одновременно открытых файлов таблиц. Позволяет уменьшить количество открытий-закрытий файлов. Стоит оценить количество файлов в каталоге, где хранятся файлы с данными MySQL и выставить значение равного порядка.
table_cache = 512
Стоит учитывать, что операционная система ограничивает количество одновременно открытых одним пользователем файлов и значение, указанное в опции, не должно быть больше разрешённого операционной системой лимита.

event_scheduler

Настройка, включающая встроенный в сервер MySQL планировщик задач. Позволяет по расписанию запускать запросы или хранимые процедуры:
event_scheduler = 1

max_connections

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

В случае веб-приложений нет особого смысла выставлять эту настройку намного больше количества процессов сервера приложения. Если в php-fpm или uwsgi для работы приложения выделено 16 процессов, то как правило каждый процесс будет устанавливать не более одного подключения к базе данных.
max_connections = 140

query_cache_size

Кэш результатов прошлых запросов. Если содержимое таблиц, фигурирующих в запросе, не менялось с момента кэширования результата предыдущего такого же запроса, то этот кэш позволит серверу сразу выдать клиенту результат запроса из кэша:
query_cache_size = 64M
Если содержимое таблиц постоянно меняется, а вероятность повторного выполнения запроса низка, то отключение этого кэша никак не скажется на производительности СУБД, но позволит сэкономить немного оперативной памяти. Для отключения кэша запросов можно указать такие опции:
query_cache_type = 0
query_cache_size = 0

general_log_file

Общий журнал. Содержит, например, сведения о запусках и остановках сервера.
general_log_file = /var/log/mysql/mysql.log

log_error

Журнал ошибок:
log_error = /var/log/mysql/mysql.err

log_warnings

Не выводить предупреждающие сообщения в журнале ошибок:
log_warnings = 0

character-set-server и collation-server

Настройка кодировки сервера по умолчанию и настроек сортировки и сравнения символов:
character-set-server = utf8
collation-server = utf8_general_ci

join_buffer_size

Буфер, используемый для соединения таблиц друг с другом. При недостаточном объёме буфера соединение будет осуществляться с использованием диска:
join_buffer_size = 16M

innodb_buffer_pool_size и innodb_buffer_pool_instances

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

Если под MySQL выделен отдельный сервер, можно рассчитать размер этого буфера исходя из общего размера доступной на сервере памяти и объёма буферов под обработку запросов от каждого из максимально возможного количества клиентов (max_connections):
innodb_buffer_pool_size = 512M
В интернете можно встретить рекомендации делить буферные пулы размерами больше гигабайта на несколько экземпляров, чтобы на каждый из экземпляров приходилось, например, по одному гигабайту:
innodb_buffer_pool_size = 10G
innodb_buffer_pool_instances = 10

innodb_flush_method

Метод записи данных в файловую систему. Часто встречается рекомендация не использовать дисковый кэш операционной системы, т.к. у сервера MySQL есть собственные буферы, а двойная буферизация замедляет работу и повышает вероятность повреждения данных:
innodb_flush_method = O_DIRECT

innodb_log_file_size, innodb_log_buffer_size и innodb_flush_log_at_trx_commit

Настройки журналов транзакций. Если в журнал данные пишутся помногу и часто, имеет смысл увеличить как размер самого журнала, чтобы серверу реже приходилось создавать новые файлы и переоткрывать их, так и увеличить размер буфера записи, чтобы снизить частоту блокирования сервера в ожидании записи в журнал транзакций:
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
Таких файлов у MySQL два. Рекомендуется, чтобы размер каждого из них составлял 1/4 от размера innodb_buffer_pool_size. Однако размер файла журнала должен быть меньше 2 гигабайт - это внутреннее ограничение MySQL.

У журнала транзакций имеется настройка, аналогичная настройке буферного пула innodb_flush_method:
innodb_flush_log_at_trx_commit = 2
Возможны следующие значения:
  • 1 - каждая транзакция после фиксации записывается на диск (наибольшая надёжность),
  • 2 - транзакция после фиксации записывается в кэш операционной системы (компромисс между надёжностью и производительностью),
  • 0 - нет требования специально сохранять данные транзакции после её фиксации, данные сохраняются по мере заполнения буфера транзакций (наибольшая производительность, но высокий риск потери данных).

Временные файлы

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

Создаём точку монтирования, например /mysql-tmp:
# cd /
# mkdir mysql-tmp
Добавляем в файл /etc/fstab строчку для монитрования раздела размером, например, 512 мегабайт:
tmpfs /mysql-tmp tmpfs relatime,nodev,nosuid,noexec,uid=mysql,gid=mysql,mode=0760,size=512M 0 0
Смонтируем временный раздел:
# mount /mysql-tmp
Теперь нужно указать в файле конфигурации сервера MySQL внутри секции server соответствующую опцию:
tmpdir = /mysql-tmp
И перезапустить MySQL:
# systemctl restart mysql
Стоит учитывать, что если места на этом разделе окажется недостаточно, запрос не выполнится и MySQL сообщит об ошибке выполнения запроса.

Značky: #linux, #mysql, #debian, #Linux

  • Wa chevron_right

    Upgrading MySQL in a Container

    pubsub.slavino.sk / warlord0blog · Friday, 3 July, 2020 - 07:51 edit

Upgrading MySQL 5.5 to 5.7 in a docker container set caused me some trouble. Setting the tag to 5.7.30 was all well and good but when I fired up the container MySQL would stop immediately. Looking at the log I found The table is probably corrupted and references to run mysql_upgrade which I was expecting &ellipsisRead the full post »

Značky: #Linux, #Virtualization, #mysql, #Linux

  • chevron_right

    Eye-Oss vs Eye-Oh-Ess: Judging the fiercest tech pronunciation debates

    news.movim.eu / ArsTechnica · Friday, 15 May, 2020 - 20:09

Eye Oh Ess.

Enlarge / Eye Oh Ess. (credit: Aurch Lawson)

A lot of people pronounce common tech terms wrong, from iOS to SQL to Qi. It's understandable: Some of the proper or official pronunciations of these terms are counterintuitive at best. Still, we think it's time to clear the air on a few of them.

It's something of a trope on tech sites to run vocabulary lists with definitions for common terms, and that makes sense. Reviewers addressing general audiences will often have to define their terms, as not everyone is as thoroughly immersed as they are.

But it's less common to see effort put into clarifying pronunciation, as differences on this front go well beyond the classic, written-about-to-death, hard-versus-soft-G GIF debate. To that end, we're going to go over a few commonly disputed pronunciations and ask Ars readers to share your insights, as well as any additional examples you think are worth discussing.

Read 11 remaining paragraphs | Comments

index?i=CENen7x_wiE:UrEDjd8y0iU:V_sGLiPBpWUindex?i=CENen7x_wiE:UrEDjd8y0iU:F7zBnMyn0Loindex?d=qj6IDK7rITsindex?d=yIl2AUoC8zA