|
MySQL.RU - Webboard
 Вернуться
 буду признателен за помощь в анализе логов (Алексей) 21/08/2017 - 10:02:29
 Re: буду признателен за помощь в анализе логов (Akina) 21/08/2017 - 10:15:42
Re: буду признателен за помощь в анализе логов (Алексей) 22/08/2017 - 18:55:54
> Original message text:
> From: Алексей - 21/08/2017 - 10:02:29
> Subject:буду признателен за помощь в анализе логов
> -----------------
> Здравствуйте, подскажите в чем может быть проблема - не могу найти узкое место в настройках MySQL - периодически происходят падения - выдержка из логов (логов больше но после данного сообщения идут крушения таблиц):
> 170818 09:26:51 mysqld_safe Number of processes running now: 0
> 170818 09:26:51 mysqld_safe mysqld restarted
> 170818 9:26:52 [Note] /usr/libexec/mysqld (mysqld 5.5.52-MariaDB) starting as process 18295 ...
> 170818 9:26:54 InnoDB: The InnoDB memory heap is disabled
> 170818 9:26:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins
> 170818 9:26:54 InnoDB: Compressed tables use zlib 1.2.7
> 170818 9:26:54 InnoDB: Using Linux native AIO
> 170818 9:26:54 InnoDB: Initializing buffer pool, size = 1.0G
> 170818 9:26:54 InnoDB: Completed initialization of buffer pool
> 170818 9:26:54 InnoDB: highest supported file format is Barracuda.
> InnoDB: Log scan progressed past the checkpoint lsn 615475503196
> 170818 9:26:54 InnoDB: Database was not shut down normally!
> InnoDB: Starting crash recovery.
> InnoDB: Reading tablespace information from the .ibd files...
> InnoDB: Restoring possible half-written data pages from the doublewrite
> InnoDB: buffer...
> InnoDB: Doing recovery: scanned up to log sequence number 615480745984
> InnoDB: Doing recovery: scanned up to log sequence number 615485988864
> InnoDB: Doing recovery: scanned up to log sequence number 615491231744
> InnoDB: Doing recovery: scanned up to log sequence number 615496474624
> InnoDB: Doing recovery: scanned up to log sequence number 615501717504
> InnoDB: Doing recovery: scanned up to log sequence number 615506960384
> InnoDB: Doing recovery: scanned up to log sequence number 615512203264
> InnoDB: Doing recovery: scanned up to log sequence number 615517446144
> InnoDB: Doing recovery: scanned up to log sequence number 615522689024
> InnoDB: Doing recovery: scanned up to log sequence number 615526177569
> 170818 9:27:10 InnoDB: Starting an apply batch of log records to the database...
> InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
> InnoDB: Apply batch completed
> 170818 9:28:50 InnoDB: Waiting for the background threads to start
> 170818 9:28:51 Percona XtraDB (http://www.percona.com) 5.5.49-MariaDB-38.0 started; log sequence number 615526177569
> 170818 9:28:51 [Note] Plugin 'FEEDBACK' is disabled.
> 170818 9:28:53 [Note] Event Scheduler: Loaded 0 events
> 170818 9:28:53 [Note] /usr/libexec/mysqld: ready for connections.
> Version: '5.5.52-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 0 MariaDB Server
> 170818 9:28:54 [ERROR] mysqld: Table './newregiontehsnab/wa_contact' is marked as crashed and should be repaired
> 170818 9:28:54 [Warning] Checking table: './newregiontehsnab/wa_contact'
> 170818 9:29:01 [ERROR] mysqld: Table './newregiontehsnab/shop_category' is marked as crashed and should be repaired
> 170818 9:29:01 [Warning] Checking table: './newregiontehsnab/shop_category'
> 170818 9:29:01 [ERROR] mysqld: Table './newregiontehsnab/shop_product' is marked as crashed and should be repaired
> 170818 9:29:01 [Warning] Checking table: './newregiontehsnab/shop_product'
> 170818 9:29:03 [ERROR] mysqld: Table './newregiontehsnab/shop_category_products' is marked as crashed and should be repaired
> 170818 9:29:03 [ERROR] mysqld: Table './newregiontehsnab/shop_category_products' is marked as crashed and should be repaired
>
From: Алексей - 22/08/2017 - 18:55:54
Subject:буду признателен за помощь в анализе логов
-----------------
это все понятно - пытаюсь причину найти разрушения таблиц
пока вот что нашел:
срабатывала служба ядра OOM Killer, предназначенная для освобождения оперативной памяти путем принудительного завершения работы процессов.
# cat /var/log/messages | grep "oom-kill"
Aug 21 09:31:50 regiontehsnab kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Aug 21 09:31:50 regiontehsnab kernel: nginx invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Aug 21 09:45:13 regiontehsnab kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
45287
|
|
