fractal Опубликовано 4 августа, 2016 · Жалоба Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 280 гигов, все ужалось до 15, но после распаковки база стала весить всего 90, причем в архиве она была показана с верным размером, это нормально? сталкиваюсь с бэкапом и восстановлением первый раз.... вообщем 2 дня назад закинул архив на сервер zabbix и он до сих пор льется, вижу что увеличивается размер занятых файлов через df и mysqladmin pr выдает update и заливка root@zabbix:~# mysqladmin pr +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | 1478 | root | localhost | zabbix | Query | 1 | update | INSERT INTO `history_uint` VALUES (47482,1464904154,1136,629019330),(47396,1464904154,4296,629019330 | | 34630 | root | localhost | | Query | 0 | | show processlist | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ root@zabbix:~# не знаю даже нормально ли это и сколько обычно восстанавливается бэкап Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 4 августа, 2016 · Жалоба Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 280 гигов, все ужалось до 15, но после распаковки база стала весить всего 90, причем в архиве она была показана с верным размером, это нормально? сталкиваюсь с бэкапом и восстановлением первый раз.... вообщем 2 дня назад закинул архив на сервер zabbix и он до сих пор льется, вижу что увеличивается размер занятых файлов через df и mysqladmin pr выдает update и заливка root@zabbix:~# mysqladmin pr +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | 1478 | root | localhost | zabbix | Query | 1 | update | INSERT INTO `history_uint` VALUES (47482,1464904154,1136,629019330),(47396,1464904154,4296,629019330 | | 34630 | root | localhost | | Query | 0 | | show processlist | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ root@zabbix:~# не знаю даже нормально ли это и сколько обычно восстанавливается бэкап Ну, я же вас предупреждал, что это будет очень долго :). Что-то у вас, конечно, 2 дня - это уж слишком... Надо бы смотреть настройки сервера, наверняка можно дотюнить. Но, поэтому лично у меня бапап забикса делается без истории. А когда пришлось мигрировать на другой сервер БД, чтоб переехать с историей, пришлось изобретать целый велосипед. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 4 августа, 2016 · Жалоба Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 280 гигов, все ужалось до 15, но после распаковки база стала весить всего 90, причем в архиве она была показана с верным размером, это нормально? сталкиваюсь с бэкапом и восстановлением первый раз.... вообщем 2 дня назад закинул архив на сервер zabbix и он до сих пор льется, вижу что увеличивается размер занятых файлов через df и mysqladmin pr выдает update и заливка root@zabbix:~# mysqladmin pr +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | 1478 | root | localhost | zabbix | Query | 1 | update | INSERT INTO `history_uint` VALUES (47482,1464904154,1136,629019330),(47396,1464904154,4296,629019330 | | 34630 | root | localhost | | Query | 0 | | show processlist | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ root@zabbix:~# не знаю даже нормально ли это и сколько обычно восстанавливается бэкап про Cold Backup читали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 5 августа, 2016 · Жалоба Нет, не читал, да бэкап был сделан с историей которое и не нужна была Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 5 августа, 2016 · Жалоба Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 280 гигов, все ужалось до 15, но после распаковки база стала весить всего 90, причем в архиве она была показана с верным размером, это нормально? сталкиваюсь с бэкапом и восстановлением первый раз.... вообщем 2 дня назад закинул архив на сервер zabbix и он до сих пор льется, вижу что увеличивается размер занятых файлов через df и mysqladmin pr выдает update и заливка root@zabbix:~# mysqladmin pr +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | 1478 | root | localhost | zabbix | Query | 1 | update | INSERT INTO `history_uint` VALUES (47482,1464904154,1136,629019330),(47396,1464904154,4296,629019330 | | 34630 | root | localhost | | Query | 0 | | show processlist | +-------+------+-----------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ root@zabbix:~# не знаю даже нормально ли это и сколько обычно восстанавливается бэкап Ну, я же вас предупреждал, что это будет очень долго :). Что-то у вас, конечно, 2 дня - это уж слишком... Надо бы смотреть настройки сервера, наверняка можно дотюнить. Но, поэтому лично у меня бапап забикса делается без истории. А когда пришлось мигрировать на другой сервер БД, чтоб переехать с историей, пришлось изобретать целый велосипед. Т.е. ранее база была 280 гигов и он теперь будет восстанавливать до этого значения? А почему распакованная база была всего 90? И как я смотрю создалось уже куча бинарных логов с заливкой бэкапа, их пока все восстанавливатся не трогаем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
FATHER_FBI Опубликовано 5 августа, 2016 · Жалоба Т.е. ранее база была 280 гигов и он теперь будет восстанавливать до этого значения? А почему распакованная база была всего 90? И как я смотрю создалось уже куча бинарных логов с заливкой бэкапа, их пока все восстанавливатся не трогаем? Бинарные логи и будут создаваться, потому что дамп это просто ***ва куча транзакций записанных в блокнот, при чтении дампа сервер выполняет все эти транзакции и они соответственно попадают в бинарный лог. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 5 августа, 2016 · Жалоба Нет, не читал, да бэкап был сделан с историей которое и не нужна была "по быстрому" надо мускуль отсановить, слить его файлы бд-файлы, затем подсунуть эти файлы другому мускулю, это и есть холодный бекап. А если через дамп делать, да на больших массивах ... много времени пройдет :) собсно вот про InnoDB, к MyISAM это тем более относится Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 5 августа, 2016 · Жалоба Т.е. ранее база была 280 гигов и он теперь будет восстанавливать до этого значения? А почему распакованная база была всего 90? И как я смотрю создалось уже куча бинарных логов с заливкой бэкапа, их пока все восстанавливатся не трогаем? Нет, будет поменьше, чем 280. В базе, у вас данные размещены иначе, чем в файле, у ним есть еще индексы, так же измененные или удаленные данные могут по прежнему занимать место. После того, как вы заливаете данные из бекапа, все записи по одной, вновь вставляются, проверяются, индексируются, и, часто это реально долго. Ибо в истории у вас сейчас миллиарды записей. Вы не будете восстанавливать удаленные/измененные данные, поэтому размер получится меньше, но насколько - предсказать сложно. Вот у меня, например, в одном заббиксе: Строк, по всем таблице - 2Г. Данные - 176.6ГиБ Индексы - 17.2ГиБ Всего - 193.7ГиБ Таблица трендов - 930М строк, 90ГБ, то есть примерно, 100 байт на строку. Там 4 bigint, 2 int, примерно 20 байт на bigint, 10 на int. В дампе, особенно если данные у вас простые, текст будет примерно такой (23271,1453582800,6,0,0,0), - всего 25 байт. Итого в дампе сжатие 1 к 4 за счет более компактной формы :). Ну, в реальности, 1 к 3 или 2 к 5 точно будет. Вот и у вас получилось. 90 к 280 - как раз 1 к 3. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 5 августа, 2016 · Жалоба Понятно, спасибо за информацию Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 6 августа, 2016 · Жалоба Бэкап льется 5 день) место уже подошло к тому сколько было ранее (284 гигабайта) root@zabbix:~# df Filesystem 1K-blocks Used Available Use% Mounted on udev 8201324 4 8201320 1% /dev tmpfs 1643324 404 1642920 1% /run /dev/dm-0 499164680 341763904 132021552 73% / none 4 0 4 0% /sys/fs/cgroup none 5120 0 5120 0% /run/lock none 8216612 0 8216612 0% /run/shm none 102400 0 102400 0% /run/user /dev/sda1 240972 48077 180454 22% /boot + 90 гигов Бэкапа которые лежат на самом же zabbix Причем группы уже появились в Web Zabbix, шаблонов, узлов, карт, графиков еще нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
FATHER_FBI Опубликовано 6 августа, 2016 (изменено) · Жалоба Бэкап льется 5 день) место уже подошло к тому сколько было ранее (284 гигабайта) root@zabbix:~# df Filesystem 1K-blocks Used Available Use% Mounted on udev 8201324 4 8201320 1% /dev tmpfs 1643324 404 1642920 1% /run /dev/dm-0 499164680 341763904 132021552 73% / none 4 0 4 0% /sys/fs/cgroup none 5120 0 5120 0% /run/lock none 8216612 0 8216612 0% /run/shm none 102400 0 102400 0% /run/user /dev/sda1 240972 48077 180454 22% /boot + 90 гигов Бэкапа которые лежат на самом же zabbix Причем группы уже появились в Web Zabbix, шаблонов, узлов, карт, графиков еще нет Вот вы извращенец) Вам важно сохранить графики? Я бы на вашем месте удалил бы всю историю и бекап занимал бы всего пару гигабайт в раскатаном виде, перенос базы сократился бы с 5 суток до нескольких минут P.S. На будущее, если Вам история не важна, перед переносом базы делайте TRUNCATE (очистку) таким таблицам как events, history, history_str, history_uint, trends_uint. Эти таблицы это 96-98% веса от всей базы. Изменено 6 августа, 2016 пользователем FATHER_FBI Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 6 августа, 2016 · Жалоба Каждый раз, когда нужно что-нибудь добавить в Cacti и я начинаю выбирать между Nagios и Zabbix, я вспоминаю, что RRD есть только на Cacti, и оставляю его. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 6 августа, 2016 · Жалоба Бэкап льется 5 день) место уже подошло к тому сколько было ранее (284 гигабайта) root@zabbix:~# df Filesystem 1K-blocks Used Available Use% Mounted on udev 8201324 4 8201320 1% /dev tmpfs 1643324 404 1642920 1% /run /dev/dm-0 499164680 341763904 132021552 73% / none 4 0 4 0% /sys/fs/cgroup none 5120 0 5120 0% /run/lock none 8216612 0 8216612 0% /run/shm none 102400 0 102400 0% /run/user /dev/sda1 240972 48077 180454 22% /boot + 90 гигов Бэкапа которые лежат на самом же zabbix Причем группы уже появились в Web Zabbix, шаблонов, узлов, карт, графиков еще нет Вот вы извращенец) Вам важно сохранить графики? Я бы на вашем месте удалил бы всю историю и бекап занимал бы всего пару гигабайт в раскатаном виде, перенос базы сократился бы с 5 суток до нескольких минут P.S. На будущее, если Вам история не важна, перед переносом базы делайте TRUNCATE (очистку) таким таблицам как events, history, history_str, history_uint, trends_uint. Эти таблицы это 96-98% веса от всей базы. эххх))) Каждый раз, когда нужно что-нибудь добавить в Cacti и я начинаю выбирать между Nagios и Zabbix, я вспоминаю, что RRD есть только на Cacti, и оставляю его. У меня и Cacti и Zabbix Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
FATHER_FBI Опубликовано 7 августа, 2016 · Жалоба Каждый раз, когда нужно что-нибудь добавить в Cacti и я начинаю выбирать между Nagios и Zabbix, я вспоминаю, что RRD есть только на Cacti, и оставляю его. Каждый раз когда выбираю между целой пачкой NMS с которыми работал, вспоминаю что 99% автоматизация есть только в zabbix) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 8 августа, 2016 · Жалоба Т.е. ранее база была 280 гигов и он теперь будет восстанавливать до этого значения? А почему распакованная база была всего 90? И как я смотрю создалось уже куча бинарных логов с заливкой бэкапа, их пока все восстанавливатся не трогаем? Нет, будет поменьше, чем 280. В базе, у вас данные размещены иначе, чем в файле, у ним есть еще индексы, так же измененные или удаленные данные могут по прежнему занимать место. После того, как вы заливаете данные из бекапа, все записи по одной, вновь вставляются, проверяются, индексируются, и, часто это реально долго. Ибо в истории у вас сейчас миллиарды записей. Вы не будете восстанавливать удаленные/измененные данные, поэтому размер получится меньше, но насколько - предсказать сложно. Вот у меня, например, в одном заббиксе: Строк, по всем таблице - 2Г. Данные - 176.6ГиБ Индексы - 17.2ГиБ Всего - 193.7ГиБ Таблица трендов - 930М строк, 90ГБ, то есть примерно, 100 байт на строку. Там 4 bigint, 2 int, примерно 20 байт на bigint, 10 на int. В дампе, особенно если данные у вас простые, текст будет примерно такой (23271,1453582800,6,0,0,0), - всего 25 байт. Итого в дампе сжатие 1 к 4 за счет более компактной формы :). Ну, в реальности, 1 к 3 или 2 к 5 точно будет. Вот и у вас получилось. 90 к 280 - как раз 1 к 3. практически 8 дней восстановления, объем уже перевалил за ту цифру что было ранее.. уже странно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalvas Опубликовано 8 августа, 2016 · Жалоба А не проще ли остановить mysql, сбросить кеши и перелить по тому-же rsync? С 1гигом займет где-то 2 суток... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 9 августа, 2016 · Жалоба Нет предыдущего заббих, сгорел сервак от грозы, даже грозозащита не спасла... остался только бэкап Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 9 августа, 2016 · Жалоба Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через truncate history.uint, как я понял она самая большая, база при этом уменьшиться? Или надо еще что то сделать? Далее хотел бы оптимизировать настройки mysql, что посоветуете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ua_mister Опубликовано 9 августа, 2016 · Жалоба Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через truncate history.uint, как я понял она самая большая, база при этом уменьшиться? Или надо еще что то сделать? Далее хотел бы оптимизировать настройки mysql, что посоветуете? Запускайте mysqltuner, он вам сам расскажет что тюнить нужно. Ну и не помешало бы сделать партицирование БД zabbix. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 9 августа, 2016 · Жалоба Я на виртуалке делал) по статье) ток что то пошло не так) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 9 августа, 2016 · Жалоба Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через truncate history.uint, как я понял она самая большая, база при этом уменьшиться? Или надо еще что то сделать? Далее хотел бы оптимизировать настройки mysql, что посоветуете? Вообще - материалов в сети более чем достаточно. Что на сервере крутится и сколько памяти можете отдать под БД? Минимально хватит следующего: innodb_file_per_table = 1 innodb_buffer_pool_size = 4G # Примерно 2/3 или 3/4 от памяти, которую можете выделить под БД. Например, если на сервере 8G, но сам заббикс сервер на то же сервере, и конфиг довольно большой, то 2G заббиксу и прочим процессам отдаем, остается 6G для БД, из них 4-5 - под innodb. Заббикс довольно много работает с временными таблицами. Поэтому tmp_table_size = 64М # Если памяти достаточно, чтоб хранить временные таблицы достаточно больших размеров в памяти. max_heap_table_size = 256M # Общее место под таблицы в памяти, с учетом пользовательских, если памяти хватает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 9 августа, 2016 · Жалоба Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через truncate history.uint, как я понял она самая большая, база при этом уменьшиться? Или надо еще что то сделать? Далее хотел бы оптимизировать настройки mysql, что посоветуете? Вообще - материалов в сети более чем достаточно. Что на сервере крутится и сколько памяти можете отдать под БД? Минимально хватит следующего: innodb_file_per_table = 1 innodb_buffer_pool_size = 4G # Примерно 2/3 или 3/4 от памяти, которую можете выделить под БД. Например, если на сервере 8G, но сам заббикс сервер на то же сервере, и конфиг довольно большой, то 2G заббиксу и прочим процессам отдаем, остается 6G для БД, из них 4-5 - под innodb. Заббикс довольно много работает с временными таблицами. Поэтому tmp_table_size = 64М # Если памяти достаточно, чтоб хранить временные таблицы достаточно больших размеров в памяти. max_heap_table_size = 256M # Общее место под таблицы в памяти, с учетом пользовательских, если памяти хватает. вообщем под сервер у меня есть 12 Гб памяти конфиг сейчас такой: # Example MySQL config file for very large systems. # # This is for a large system with memory of 1G-2G where the system runs mainly # MySQL. # # MySQL programs look for option files in a set of # locations which depend on the deployment platform. # You can copy this option file to one of those # locations. For information about these locations, see: # http://dev.mysql.com/doc/mysql/en/option-files.html # # In this file, you can use all long options that a program supports. # If you want to know which options a program supports, run the program # with the "--help" option. # The following options will be passed to all MySQL clients [client] #password = your_password port = 3306 socket = /var/run/mysqld/mysqld.sock # Here follows entries for some specific programs # The MySQL server [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 skip-external-locking key_buffer_size = 384M max_allowed_packet = 1M table_open_cache = 512 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M innodb_file_per_table = 1 innodb_data_file_path=ibdata1:10M:autoextend:max:15G innodb_buffer_pool_size = 10G # Try number of CPU's*2 for thread_concurrency thread_concurrency = 8 # Don't listen on a TCP/IP port at all. This can be a security enhancement, # if all processes that need to connect to mysqld run on the same host. # All interaction with mysqld must be made via Unix sockets or named pipes. # Note that using this option without enabling named pipes on Windows # (via the "enable-named-pipe" option) will render mysqld useless! # #skip-networking # Replication Master Server (default) # binary logging is required for replication log-bin=mysql-bin # required unique id between 1 and 2^32 - 1 # defaults to 1 if master-host is not set # but will not function as a master if omitted server-id = 1 # Replication Slave (comment out master section to use this) # # To configure this host as a replication slave, you can choose between # two methods : # # 1) Use the CHANGE MASTER TO command (fully described in our manual) - # the syntax is: # # CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>, # MASTER_USER=<user>, MASTER_PASSWORD=<password> ; # # where you replace <host>, <user>, <password> by quoted strings and # <port> by the master's port number (3306 by default). # # Example: # # CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306, # MASTER_USER='joe', MASTER_PASSWORD='secret'; # # OR # # 2) Set the variables below. However, in case you choose this method, then # start replication for the first time (even unsuccessfully, for example # if you mistyped the password in master-password and the slave fails to # connect), the slave will create a master.info file, and any later # change in this file to the variables' values below will be ignored and # overridden by the content of the master.info file, unless you shutdown # the slave server, delete master.info and restart the slaver server. # For that reason, you may want to leave the lines below untouched # (commented) and instead use CHANGE MASTER TO (see above) # # required unique id between 2 and 2^32 - 1 # (and different from the master) # defaults to 2 if master-host is set # but will not function as a slave if omitted #server-id = 2 # # The replication master for this slave - required #master-host = <hostname> # # The username the slave will use for authentication when connecting # to the master - required #master-user = <username> # # The password the slave will authenticate with when connecting to # the master - required #master-password = <password> # # The port the master is listening on. # optional - defaults to 3306 #master-port = <port> # # binary logging - not required for slaves, but recommended #log-bin=mysql-bin # # binary logging format - mixed recommended #binlog_format=mixed # Uncomment the following if you are using InnoDB tables #innodb_data_home_dir = /var/lib/mysql #innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend #innodb_log_group_home_dir = /var/lib/mysql # You can set .._buffer_pool_size up to 50 - 80 % # of RAM but beware of setting memory usage too high #innodb_buffer_pool_size = 384M #innodb_additional_mem_pool_size = 20M # Set .._log_file_size to 25 % of buffer pool size #innodb_log_file_size = 100M #innodb_log_buffer_size = 8M #innodb_flush_log_at_trx_commit = 1 #innodb_lock_wait_timeout = 50 [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash # Remove the next comment character if you are not familiar with SQL #safe-updates [myisamchk] key_buffer_size = 256M sort_buffer_size = 256M read_buffer = 2M write_buffer = 2M [mysqlhotcopy] interactive-timeout но могу памяти отдать и 16 гб, проц 8 ядер Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 9 августа, 2016 · Жалоба нормально будет если я почищу - TRUNCATE alerts; TRUNCATE acknowledges; TRUNCATE events; TRUNCATE auditlog; TRUNCATE auditlog_details; TRUNCATE history; TRUNCATE history_unit; TRUNCATE history_log; TRUNCATE history_str; TRUNCATE history_text; TRUNCATE services_alarms; TRUNCATE trends; TRUNCATE trends_uint; Далее SELECT CONCAT("OPTIMIZE TABLE ",TABLE_SCHEMA,".",TABLE_NAME,";") FROM TABLES WHERE table_schema = 'zabbix' into outfile '/tmp/a.txt'; мне ток историю почистить и оптимизировать место?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 9 августа, 2016 · Жалоба вообщем под сервер у меня есть 12 Гб памяти конфиг сейчас такой: ... # Replication Master Server (default)# binary logging is required for replication log-bin=mysql-bin Это зачем? У вас есть кластер? Из 12 отдать 10 под Innodb - это моноговато, если у вас еще и сервер заббикс там, тем более с большим количеством хостов и параметров. 6-8 достаточно. Посмотрите на свой своп. И по временным таблицам, посмотрите текущие параметры, поправьте, если надо. query_cache_size, myisam_sort_buffer_size можете вообще убрать, у вас не myisam а innodb должно быть. но могу памяти отдать и 16 гб, проц 8 ядер Тут вопрос в том, сколько реально вам нужно :). Судя по всему, вы ограничены не в памяти, а в дисковой подсистеме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 9 августа, 2016 (изменено) · Жалоба вообщем под сервер у меня есть 12 Гб памяти конфиг сейчас такой: ... # Replication Master Server (default)# binary logging is required for replication log-bin=mysql-bin Это зачем? У вас есть кластер? Из 12 отдать 10 под Innodb - это моноговато, если у вас еще и сервер заббикс там, тем более с большим количеством хостов и параметров. 6-8 достаточно. Посмотрите на свой своп. И по временным таблицам, посмотрите текущие параметры, поправьте, если надо. query_cache_size, myisam_sort_buffer_size можете вообще убрать, у вас не myisam а innodb должно быть. но могу памяти отдать и 16 гб, проц 8 ядер Тут вопрос в том, сколько реально вам нужно :). Судя по всему, вы ограничены не в памяти, а в дисковой подсистеме. вообщем памяти стояло 24 гига (zabbix на виртуалке крутиться esxi) поэтому 10Гб, но т.к. пока использует он не сильно много, хочу выдать ему 12 и под innodb 6 гигов, далее все крутится на одном серваке (zabbix), кластера нет, в объемах ограничен 1 Tb, на серваке raid 10 из 4-х двухтерабайтных ssd, сейчас мне надо хранить точные данные всего 1-2 месяца и тренды 4 месяца, поэтому хочу как то базу оптимизировать Изменено 9 августа, 2016 пользователем fractal Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...