@ZabbixPro

Страница 945 из 1183
Full
06.07.2018
10:08:27
Это как Халву 3 ждать. :)

В том смысле, что функционала будет не хватать всегда, и всегда что-то будет добавляться в следующей версии. Что-то очень нужное. И так ждать можно бесконечно от версии к версии.

Некто
06.07.2018
10:14:40
мм.. я пока впал в ступор... видимо может и не получиться. я написал баш-скрипт с expect'ом, при помощи которого планировал осуществлять ллд. в скрипте перечислены регулярки, при помощи которых я получаю номера xml-блоков одного типа. условно считая, что каждый номер - уникален и может служить фильтром для дальнейшего разбора , а количество блоков равно количеству физхических элементов. например, в том джейсоне который я ранее выкладывал, перечислены OIDы всех физ. дисков. и всё шло хорошо до тех пор, пока я не начал делать прототип... прототипом является telnet-запрос с препроцессингом. ключ: telnet.run[hp-msa-lld-disks,{HOST.CONN},23,utf8] скрипт: set cli-parameters base 10 api brief enabled pager disabled show disks этот прототип вызывает полный xml-перечень данных по всем дискам полки. чтобы отфильтровать только данные по текущему {#HP_MSA_DISK_OID}, я планировал использовать препроцессинг такого вида: регулярка: (?=<OBJECT basetype="drives" name="drive" oid="{#HP_MSA_DISK_OID}".*)((?s).*?<\/OBJECT>) далее я бы сделал зависимые прототипы, зависящие от этого корневого. и вот тут я застрял. складываетсяы впечатление, что макрос {#HP_MSA_DISK_OID} не работает в выражении регулярки препроцессинга. и именно в этом причина того, что несмотря на корректность всех данных у меня выдаётся ошибка LLD.
Препроцессор не все JSON ключи жрет. с дефисом жрет, с подчеркиванием - нет.

Google
Nikolay
06.07.2018
10:16:08
попробуй xtrabackup вместо mysqldump

а ограничить по памяти - вроде же innodb_buffer_pool_size = XXG где XXGb — это 70…80% от RAM сервера

Evgeniy
06.07.2018
10:17:52
что-то странное. у меня на сервере с 4-мя гигами никогда подобного не было. базу дампил под 100 гиг

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

Nikolay
06.07.2018
10:19:49
и быстрее и надежнее и без простоя сервиса

Evgeniy
06.07.2018
10:20:17
а восстанавливать такой дамп - ваще печаль.

Nikolay
06.07.2018
10:20:56
при xtrabackup только важно правильный innodb_log_file_size выставить для СУБД

Ilya
06.07.2018
10:21:02
Я бы рекомендовал делать через mysqldump слепок конфигурации, особенно, если меняется часто. Весит мало, и между "потерять всё" и "потерять историю" – выбрать второе проще.

Evgeniy
06.07.2018
10:21:37
оно все файлы бд бэкапит. если совсем просто говорить

Ilya
06.07.2018
10:22:25
плюсую схему базы + процедуры через дамп (1 сек) а таблицы и все все все — через экстрабекап
Ну схема есть и в сорцах) Я имею в виду хосты+айтемы и тд. Там пара десятков мб. ?

Nikolay
06.07.2018
10:22:55
у меня не стандартная немножко схема )

ну тут да, важна концепция. получается очень гибко в итоге

Google
Nikolay
06.07.2018
10:23:39
скока RAM и какое значение?

в своп наверное сам mysqldump лезет. а не БД

по нему не подскажу ?

Ilya
06.07.2018
10:24:27
вот это отличная идея
grep -Ev '(^history|^events$|^trends$|^auditlog$|^auditlog_details$|^trends_uint$)'

Evgeniy
06.07.2018
10:25:12
а есть хоть какие-то намеки почему в свап-то уходит? имхо пока делается дамп, много данных приходит. а таблица на локе

Nikolay
06.07.2018
10:25:47
в своп точно mysql лезет? а не mysqldump?

Evgeniy
06.07.2018
10:26:15
еще интереснее

Alexander
06.07.2018
10:26:47
на живой базе ничего не сделает

Nikolay
06.07.2018
10:28:18
на живой базе ничего не сделает
бывает что пока innobackupex копирует файлы БД в них успевает насыпаться больше, чем умещается в логи. и тогда он не может накатить транзакции и говорит "ой все!" бекапа не будет

очень просто проверить — запусти muysqldump с другой машины

и будет видно кто виноват

Alexander
06.07.2018
10:29:38
--single-transaction --quick

покажи настройки my.cnf и скажи сколько памяти и ядер

настройки my.cnf в пастебин чтобы тут не гадить

Nikolay
06.07.2018
10:35:50
Ставлю 100р что это MySQLdump не вмещается в память

Alexander
06.07.2018
10:36:10
сколько у тебя памяти на сервере?

Nikolay
06.07.2018
10:36:30
Оно?

Google
Alexander
06.07.2018
10:36:54
что кроме мускуля крутится?

покажи top

топ покажи

не сказал какая версия ос

БД

не видно настроек

Full
06.07.2018
10:41:23
Из практики - дампил базу заббикса 350Гб mysqldump'ом на сервере с 4 Гб ОЗУ. Все было норм, только долго. Подробностей не будет - за давностью лет не помню деталей.

Alexander
06.07.2018
10:43:18
evgeny а дампишь на тот же диск физический где и база?

Nikolay
06.07.2018
10:43:21
а воостановление из дампа часто делаете? сколько времени уходит на рестор 100Гб?

Alexander
06.07.2018
10:44:44
а что за СХД?

как-то уныло на ссд видеть 5.7 iowait

Admin
ERROR: S client not available

Alexander
06.07.2018
10:45:22
а дамп идет в sql или сразу налету в gzip?

а какие опции для mysqldump используются?

mysqldump --single-transaction --quick --databases DB | gzip > DB.sql.gz

и должно ехать

гзипом ты ускоришь процесс

не понял

Evgeniy
06.07.2018
10:48:34
поясни

Google
Alexander
06.07.2018
10:48:46
файл пер тейбл?

для иннодб?

Evgeniy
06.07.2018
10:48:54
иннодб файл пер табле?

Alexander
06.07.2018
10:49:08
надо сдампить грохнуть и отресторить

Evgeniy
06.07.2018
10:49:24
заебесси восстанавливать дамп...

Alexander
06.07.2018
10:49:28
а можно в рядом базу положить

Evgeniy
06.07.2018
10:49:42
история за большой период?

Alexander
06.07.2018
10:50:13
создал новую базу

перед этим применил настройку про файл пер тейбл

перегнал в новую базу данные

но я бы посмотрел почему 350 гиг и почикал бы хорошо БД

Alexander
06.07.2018
10:51:27
да как угодно

Evgeniy
06.07.2018
10:51:28
сам не так двно вот это все делал

Alexander
06.07.2018
10:51:48
я б просто сначала перед дампом прошелся бы по таблицам и посмотрел каунты по каждой

Страница 945 из 1183