-
chevron_right
Au fait, pourquoi SQL s’appelle SQL ?
news.movim.eu / Numerama · Sunday, 18 December - 18:55
Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/
Au fait, pourquoi SQL s’appelle SQL ?
news.movim.eu / Numerama · Sunday, 18 December - 18:55
Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/
La mort de Vanilla Forums
Loïck · Friday, 21 October - 21:26 edit
Nous nous trouvons maintenant devant la mort du logiciel de forum Vanilla. Let's go sur le post concerné que j'ai publié sur le site de Vanilla Forums.
ESP8266 and MySQL with Grafana
pubsub.slavino.sk / arduinodiy · Saturday, 9 July, 2022 - 11:18 edit
MySQL vs MariaDB: What Are the Main Differences Between Them (MariaDB is actually forked from MySQL)
GadgeteerZA · news.movim.eu / gadgeteerza-tech-blog · Wednesday, 6 October, 2021 - 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/
Oracle accelerates MySQL HeatWave queries with machine learning
pubsub.slavino.sk / infoworldcom · Tuesday, 10 August, 2021 - 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
13 Tips for Tuning and Optimizing MySQL and MariaDB Databases
GadgeteerZA · news.movim.eu / gadgeteerza-tech-blog · Thursday, 5 August, 2021 - 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/
MySQL 101: Installation, care, and feeding on Ubuntu
Jim Salter · news.movim.eu / ArsTechnica · Friday, 11 June, 2021 - 19:23
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.
If you're even vaguely familiar with Ubuntu or Debian, the installation process shouldn't be surprising: apt install mysql-server and you're off to the races. [credit: Jim Salter ]
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).
История и тенденции Zabbix в TokuDB
pubsub.slavino.sk / sysadmblog · Sunday, 16 August, 2020 - 08:00 edit · 6 minutes
# 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. Необходимо установить соответствующий пакет и исправить путь к файлу в файле конфигурации.
$ 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Осталось перезагрузить систему и убедиться в том, что прозрачная поддержка огромных страниц действительно отключилась.
DROP TABLE history;Если же нужно выполнить миграцию существующей инсталляции Zabbix, тогда лучше сначала переименовать существующие таблицы истории и тенденций:
DROP TABLE history_uint;
DROP TABLE history_str;
DROP TABLE history_log;
DROP TABLE history_text;
DROP TABLE trends;
DROP TABLE trends_uint;
RENAME TABLE history TO history_bak;Вместо прежних таблиц нужно будет создать новые пустые таблицы истории и тенденций, сначала без разбивки на секции, с помощью следующих SQL-запросов:
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;
CREATE TABLE `history` (Эти таблицы пока не разбиты на секции, но уже используют движок TokuDB, сжатие данных по алгоритму LZMA и используют кластерные индексы - индексы, хранящиеся вместе с индексируемыми данными.
`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;
#!/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
$ 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_cache_size = 8G ; default = 12G ?Я ограничился указанием подходящего значения tokudb_cache_size и изменением следующих настроек:
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_directio = ON
tokudb_row_format = tokudb_lzma
tokudb_empty_scan = disabled
6619:20200604:000100.756 [Z3005] query failed: [1526] Table has no partition for value 1591210860 [insert into historyЕсли новые секции таблиц не создаются автоматически, то первым делом вручную вызываем обслуживание таблиц, чтобы сервер Zabbix мог начать писать данные:
(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);
]
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_upgrade --force -uroot -p mysqlЗатем пересоздаём запланированное задание:
$ mysql_upgrade --force -uroot -p zabbix
USE `zabbix`;И напоследок перезапускаем сервер MariaDB:
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 ;
# systemctl restart mariadbКакое из приведённых решений помогает на самом деле, сказать точно не могу, т.к. я пробовал использовать каждый из советов поодиночке и не установил чёткой закономерности, какой из них помогает всегда. Иногда одно действие не лечит проблему и на следующий день можно заметить, что новые секции опять не создались.
Značky: #linux, #stretch, #buster, #mariadb, #debian, #zabbix, #Linux, #mysql, #3.4, #tokudb
Настройка сервера MySQL
pubsub.slavino.sk / sysadmblog · Sunday, 9 August, 2020 - 08:00 edit · 1 minute
expire_logs_days = 1Однако, если вы используете репликацию данных на другой сервер, журналы стоит хранить за такой период времени, который может понадобиться на восстановление репликации при её поломке. В противном случае придётся повторно копировать данные с ведущего сервера на ведомый.
transaction_isolation = REPEATABLE-READДля уверенности стоит поискать настройки, рекомендуемые разработчиками приложения. Если информации найти не удалось, более безопасным выбором будет REPEATABLE-READ.
innodb_file_per_table = 1
table_cache = 512Стоит учитывать, что операционная система ограничивает количество одновременно открытых одним пользователем файлов и значение, указанное в опции, не должно быть больше разрешённого операционной системой лимита.
event_scheduler = 1
max_connections = 140
query_cache_size = 64MЕсли содержимое таблиц постоянно меняется, а вероятность повторного выполнения запроса низка, то отключение этого кэша никак не скажется на производительности СУБД, но позволит сэкономить немного оперативной памяти. Для отключения кэша запросов можно указать такие опции:
query_cache_type = 0
query_cache_size = 0
general_log_file = /var/log/mysql/mysql.log
log_error = /var/log/mysql/mysql.err
log_warnings = 0
character-set-server = utf8
collation-server = utf8_general_ci
join_buffer_size = 16M
innodb_buffer_pool_size = 512MВ интернете можно встретить рекомендации делить буферные пулы размерами больше гигабайта на несколько экземпляров, чтобы на каждый из экземпляров приходилось, например, по одному гигабайту:
innodb_buffer_pool_size = 10G
innodb_buffer_pool_instances = 10
innodb_flush_method = O_DIRECT
innodb_log_file_size = 256MТаких файлов у MySQL два. Рекомендуется, чтобы размер каждого из них составлял 1/4 от размера innodb_buffer_pool_size. Однако размер файла журнала должен быть меньше 2 гигабайт - это внутреннее ограничение MySQL.
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2Возможны следующие значения:
# cd /Добавляем в файл /etc/fstab строчку для монитрования раздела размером, например, 512 мегабайт:
# mkdir mysql-tmp
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 сообщит об ошибке выполнения запроса.