• 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

    • chevron_right

      Upgrading MySQL in a Container

      Warlord · 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

      Movim 0.15 – Donati

      Timothée Jaussoin · pubsub.movim.eu / Movim · Sunday, 28 July, 2019 - 12:59 · 4 minutes

    After months of work, Movim 0.15 is finally out!

    This version was planned as a 0.14.2 but was finally retagged as a major release regarding the number of changes, improvements and new features introduced. This #release note will also sum up the changes introduced in the minor 0.14.1 version.

    So what's new in Movim?

    User features

    Local nicknames

    In the configuration panel you can now set a local nickname, this allows you to shorten the identifier you are using on your current pod and gives you a nice looking url for your blog (https://nl.movim.eu/?blog/edhelas%40movim.eu/ becomes https://nl.movim.eu/?blog/edhelas).

    Chats reactions

    In one-to-one chats and chatrooms you can add and remove #reactions to your contacts messages. A first implementation was using the Message Attaching XMPP extension. During the Lyon XMPP Sprint, the feature was refactored to implement the incoming XEP - Message Reactions. During this sprint we also worked with the #Dino and #Poezio developers to make the feature fully compatible with their clients.

    Chat reactions

    Publication sharing

    You can now easily share any article found in Movim inside a conversation by clicking on the send button just bellow the article.

    This uses the References XMPP extension.

    Publication sharing

    Snap!

    Do you want to quickly snap a picture and directly send it to a friend in a discussion or in an article? The new #Snap feature allows you to do that from any devices. Switch between your different cameras, shoot and send. It's that easy!

    The Android application has been updated as well to integrate this feature properly.

    Small improvements

    • You can now slide a one to one discussion to close it quickly, just like the Conversations client allows you to.
    • Search navigation has been improved, there is no page reload anymore to open a new discussion from the Search panel.
    • The Community page was fully redesigned to be snappier and propose contents that might interest you.
    • The UI now handles small disconnections way better . The conversations are not fully reloaded anymore when the connection is brought back.
    • In the configuration you can now define the Chat page as the default one to open when launching Movim, this is quite useful on mobile.

    Fixes, fixes, many fixes

    Lots of small things were fixed here and there.

    • The chat notifications counter was fully refactored to prevent some counter issues, each message is now independently checked as read (or not) in the database
    • The composing/paused chat state are now handled more properly in Movim. Those states are also displayed during chatrooms discussions. This fixes a 3 years old ticket.
    • Websockets are now reconnected properly if the browser is doing some intensive throttling, this was especially the case on Chrome on mobile devices.

    Architecture and technical changes

    From ZeroMQ to Websockets

    One of the biggest changes technically wise was the replacement of #ZeroMQ sockets with WebSockets. This technology was used internally for the inter-processes communications. In the end this replacement allows us to become independent from the php-zmq library without any noticeable performance impact.

    This simplifies even more the deployment of Movim and helps with the packaging of the project.

    New base web server directory

    For the administrators, please notice that the main file, index.php is not at the root of the project anymore but in the public/ directory (as well as many other files). These small changes allow the Web server to expose only the public files without extra configuration. So please point your root repository to that public subfolder.

    This change was about securing the basic setup by default .

    SQLite support removed

    The #SQLite support, introduced in the version 0.14, has been removed for now. We had lots of issues to maintain consistency and fix our migrations for that specific database.

    Some work has been done on the Eloquent library to fix some of those migrations issues upstream but it is too early to have something sufficient to bring back SQLite support in Movim.

    You can still fully use Movim with #MySQL and #PostgreSQL.

    What's next?

    Movim has now reached a stable state, both UX/UI wise as architecturally wise.

    There is still a lot of improvements to do, especially regarding the integration between the social network part and the chat part. Plus, we are always interested to hear about new ideas or improvement suggestions!

    For the 0.16 version we are planning to improve video-conferencing and bring it properly for the mobile devices. Some work is also planned to improve the Communities navigation.

    We need your help

    To continue developing and hosting our infrastructure and to support the project we would be really pleased to cover our monthly expenses, it's not much.

    We already have a few hundreds users connected daily on our main servers. If each of them could give a few euros per month it would easily allow us to reach that goal.

    You can help us by giving monthly on our official Patreon page or by using Paypal.

    • chevron_right

      Movim 0.14 - Scotty - Anniversary Edition

      Timothée Jaussoin · pubsub.movim.eu / Movim · Sunday, 18 November, 2018 - 09:17 edit · 5 minutes

    Movim is 10 years old and it's with a lot of satisfaction that we are bringing this version 0.14 after 9 long months of development.

    Movim is a new concept of social network with instant messaging features that sits between #Instagram, #WhatsApp for the user experience and federated networks such as #Diaspora or #Mastodon.

    Ou goal is to bring everything you need to communicate with your community, classroom, company or friend circle in one simple application. Movim can easily be deployed on a server and rely on the XMPP protocol to federate them. Therefore Movim can, by design, already communicate with many XMPP/Jabber clients and doesn't need you to create a new account if you already have an XMPP one 😋.

    This new #release is coming with several core changes that greatly improved the stability and performances of the project but it also brings many design and navigation improvements to always provide you with the best experience regarding publication of content and messaging.

    Movim and PHP 7.3

    Movim is currently having technical issues to run on the upcoming version of PHP 7.3.

    This is a known and documented issue that is caused by some incompatibilities with one of the official dependencies of PHP, php-zmq, that is used at several places in the core of the daemon.

    A ticket has been open to track and give updates about this issue: Movim is not working with PHP 7.3.

    Technical changes

    Before presenting the improvements and new features let's talk a bit about what was done under the hood.

    Database

    The biggest change in this version is certainly the complete replacement of the database layer from the historical, Movim specific, Modl library to the widely used Eloquent.

    This work has been detailed in a previous article: From Modl to Eloquent, or how to change a social network database engine. To sum it up, it brought coherence in the database of the project and a huge performance boost on all the pages.

    Without any cache involved, Movim is now loading pages in only a few hundred milliseconds.

    A little chart, people always like charts

    The new database structure is also keeping good performances with a huge amount of data (millions of messages, thousands of articles on our official pods a this moment).

    With Eloquent, Movim is compatible with #MySQL, #PostgreSQL but also, since this version, with #SQLite which can greatly simplify the deployment of small instances. Thanks to JKingweb for his awesome work on this port.

    Packaging and dependencies

    Scotty will be the first version to be packaged for the #Debian project. Big improvements were made in the dependencies of the project thanks to the work of our contributors mirabilos and nik. Several were fully removed and some are replaced with more stable and reliable ones (like the SASL library, used for the authentication). This package will come a bit later regarding the issue that we have with PHP 7.3.

    Movim 0.14 is also the first version to drop the support of PHP5 (now deprecated) to focus on PHP7+.

    What's new?

    After being a bit boring with those technical changes let's have a look at what you will find as a user in this new version.

    Publications

    The publication of articles is now simpler than ever and has been fully redesigned. You can quickly publish a link or upload a picture directly from the home page or you can still switch to the more complete form to write long articles (like this one 😉).

    A more simple publication form

    When sharing a link that contains several pictures you can now pick the one that you would like to include in your publication (or no picture at all).

    Picking the perfect kitten picture :3

    The publication visibility toggle has been redesigned to be clearer as well.

    Articles

    The cards containing the preview of the articles were fully redesigned to be more compact and adaptable to smaller screens.

    The news page, contact publications and communities are now paginated allowing simpler navigation.

    If you receive articles containing NSFW content and you asked to not display them in the configuration, Movim will now display a spoiler overlay on top of them.

    Click on the spoiler to show the content

    The search feature has been improved and now supports searching in tags as well.

    The loading performances of the articles and comments were also greatly improved. Navigating between the articles feels like a breeze.

    Notifications

    All the notifications are now grouped in a panel easily available from the main menu both on desktop and on mobile. Thanks to XMPP all those notifications are received and synchronized in real time 😀.

    The new notifications panel

    Those notifications contain likes, comments and invitations that you received.

    Chats

    Several message synchronisation issues were fixed allowing Movim to handle properly the receival and read acknowledgement of the sent messages.

    Chatrooms

    The chatrooms were slightly redesigned, the moderators messages are now shown with a specific color. The messages addressed to you are also displayed with a colored border.

    Improved design for the chatrooms

    You can now also publish Stickers and emojis in your favorite chatrooms.

    But also!

    You can now use Movim to authenticate to third party websites using your XMPP account. On the websites that implement that feature, you just have to give your XMPP account and a notification will be displayed in Movim.

    The authentication notification

    You just have to accept it and you'll be automatically authenticated to the external website. How easy is it?

    More information there Journal of a Bot - Authentication with XMPP.

    Several small bugs were also fixed in the Video Conference feature. Movim is now clearer about the state of the video session and is giving proper feedbacks if the contact hung-up.

    The pictures can be directly previewed within Movim before going to the external link.

    Around the project

    The new redesigned version of the official website will now present more clearly what the project is about and all the exciting features that you can use within Movim.

    You will also find there all the apps for your desktop (Windows, macOS, Linux) and your Android phone.

    What's next?

    We are not done yet! There is already some plans for the upcoming release.

    The 0.15 will focus on the integration of the OMEMO end to end encryption protocol. The related ticket has been reopened with more proper explanations. This will be a big risky project.

    Some improvements will also be done on the suggestions of the chatrooms and communities to allow Movim users to explore and discover content more easily.

    In the meantime we all invite you to try out this new version on our official instances or deploy it on your server. You will find everything to do so on the official website.

    You can also always help us with donation to the project or support us on Liberapay or Patreon :). Giving feedbacks or talking about Movim around you is also helping us a lot!

    That's all folks!