[fractal]

Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 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:~#

 

не знаю даже нормально ли это и сколько обычно восстанавливается бэкап

[SergeiK]

Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 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 дня - это уж слишком... Надо бы смотреть настройки сервера, наверняка можно дотюнить.

 

Но, поэтому лично у меня бапап забикса делается без истории.

А когда пришлось мигрировать на другой сервер БД, чтоб переехать с историей, пришлось изобретать целый велосипед.

[ichthyandr]

Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 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 читали?

[fractal]

Нет, не читал, да бэкап был сделан с историей которое и не нужна была

[fractal]

Вообщем ситуация следующая, слил бэкап базы данных в архив, база была 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? И как я смотрю создалось уже куча бинарных логов с заливкой бэкапа, их пока все восстанавливатся не трогаем?

[FATHER_FBI]

Т.е. ранее база была 280 гигов и он теперь будет восстанавливать до этого значения? А почему распакованная база была всего 90? И как я смотрю создалось уже куча бинарных логов с заливкой бэкапа, их пока все восстанавливатся не трогаем?

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

[ichthyandr]

Нет, не читал, да бэкап был сделан с историей которое и не нужна была

"по быстрому" надо мускуль отсановить, слить его файлы бд-файлы, затем подсунуть эти файлы другому мускулю, это и есть холодный бекап. А если через дамп делать, да на больших массивах ... много времени пройдет :)

собсно вот про InnoDB, к MyISAM это тем более относится

[SergeiK]

Т.е. ранее база была 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.

[fractal]

Понятно, спасибо за информацию

[fractal]

Бэкап льется 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, шаблонов, узлов, карт, графиков еще нет

[FATHER_FBI]

Бэкап льется 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

[alibek]

Каждый раз, когда нужно что-нибудь добавить в Cacti и я начинаю выбирать между Nagios и Zabbix, я вспоминаю, что RRD есть только на Cacti, и оставляю его.

[fractal]

Бэкап льется 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

[FATHER_FBI]

Каждый раз, когда нужно что-нибудь добавить в Cacti и я начинаю выбирать между Nagios и Zabbix, я вспоминаю, что RRD есть только на Cacti, и оставляю его.

Каждый раз когда выбираю между целой пачкой NMS с которыми работал, вспоминаю что 99% автоматизация есть только в zabbix)

[fractal]

Т.е. ранее база была 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 дней восстановления, объем уже перевалил за ту цифру что было ранее.. уже странно

[vitalvas]

А не проще ли остановить mysql, сбросить кеши и перелить по тому-же rsync?

С 1гигом займет где-то 2 суток...

[fractal]

Нет предыдущего заббих, сгорел сервак от грозы, даже грозозащита не спасла... остался только бэкап

[fractal]

Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через truncate history.uint, как я понял она самая большая, база при этом уменьшиться? Или надо еще что то сделать? Далее хотел бы оптимизировать настройки mysql, что посоветуете?

[ua_mister]

Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через truncate history.uint, как я понял она самая большая, база при этом уменьшиться? Или надо еще что то сделать? Далее хотел бы оптимизировать настройки mysql, что посоветуете?

 

Запускайте mysqltuner, он вам сам расскажет что тюнить нужно. Ну и не помешало бы сделать партицирование БД zabbix.

[fractal]

Я на виртуалке делал) по статье) ток что то пошло не так)

[SergeiK]

Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через 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 # Общее место под таблицы в памяти, с учетом пользовательских, если памяти хватает.

[fractal]

Вообщем восстановление завершилось, база занимает места ровно столько же сколько и ранее, теперь хочу оптимизировать, для начала очистить историю через 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 ядер

[fractal]

нормально будет если я почищу -

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';

 

мне ток историю почистить и оптимизировать место?)

[SergeiK]

вообщем под сервер у меня есть 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 ядер

Тут вопрос в том, сколько реально вам нужно :).

Судя по всему, вы ограничены не в памяти, а в дисковой подсистеме.

[fractal]

вообщем под сервер у меня есть 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