
Alexander
06.07.2018
10:07:51

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
оно все файлы бд бэкапит. если совсем просто говорить

Nikolay
06.07.2018
10:21:48

Ilya
06.07.2018
10:22:25

Nikolay
06.07.2018
10:22:55
у меня не стандартная немножко схема )
ну тут да, важна концепция. получается очень гибко в итоге

Google

Evgeniy
06.07.2018
10:23:15

Nikolay
06.07.2018
10:23:39
скока RAM и какое значение?
в своп наверное сам mysqldump лезет. а не БД
по нему не подскажу ?

Ilya
06.07.2018
10:24:27

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 гиг и почикал бы хорошо БД

Evgeniy
06.07.2018
10:51:14

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

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

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