мускул то?

Да :)

Да :)

помойму он всё слушает , в файрволе в исключениях

Илии только через сокет принимает соединения?

ну щас посмотрю

sudo netstat -tnlp|grep 3306

sudo netstat -tnlp|grep 3306

tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 30473/mysqld

sudo netstat -tnlp|grep 3306

мб конфиги постфикса неправильные?

мб конфиги постфикса неправильные?

Может

sudo netstat -tnlp|grep 3306

не могу понять в чем проблема

Может

какие действия предпринять?

mysql чатике спросить аналог постгресовых json_agg или xml_agg

:Д

нет такого в mysql

страдать придется

:(

mysql чатике спросить аналог постгресовых json_agg или xml_agg

в 8.0 появился json_arrayagg()

А 6 ой и 7 ой mysql пропущен?)

5.6 -> 5.7 -> 8

просто поняли, что минорные больше тянут на мажорные, и сменили схему

с джавой та же история

5.6 -> 5.7 -> 8

А 8 уже зарелизили?

http://mysqlserverteam.com/the-mysql-8-0-0-milestone-release-is-available/

development milestone release? что?

Вместе с тем 8.0.1 давно доступен https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-1.html Я не очень понимаю, что именно они зарелизили

> Support for DTrace has been removed. эээ

короче база падает вот логи. 170430 16:13:42 [ERROR] mysqld: Out of memory (Needed 6045600 bytes) 170430 16:13:42 [ERROR] Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap spac 170430 16:13:42 [ERROR] mysqld got signal 11 ; ну тут все понятно. памяти мало. но, есть 2 сервак. с полностью аналогичными версиями марии и концигами. и там тоже вот такая ошибка [ERROR] mysqld got signal 11 ; 170615 10:29:00 InnoDB: Completed initialization of buffer pool 170615 10:29:00 InnoDB: highest supported file format is Barracuda. 170615 10:29:01 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. 170615 10:29:01 InnoDB: Error: trying to open a table, but could not InnoDB: open the tablespace file './host_474283_azyk/wz0yt_content.ibd'! InnoDB: Have you moved InnoDB .ibd files around without using the InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? InnoDB: It is also possible that this is a temporary table #sql..., InnoDB: and MySQL removed the .ibd file for this. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 170615 10:29:01 InnoDB: Waiting for the background threads to start 170615 10:29:02 Percona XtraDB (http://www.percona.com) 5.5.52-MariaDB-38.3 started; log sequence number 395626559838 170615 10:29:02 [Note] Plugin 'FEEDBACK' is disabled. 170615 10:29:02 [Note] Server socket created on IP: '127.0.0.1'. 170615 10:29:02 [Note] Event Scheduler: Loaded 0 events 170615 10:29:02 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.53-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 170615 10:29:02 [Note] Event Scheduler: scheduler thread started with id 1 170615 10:31:09 [ERROR] mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see http://kb.askmonty.org/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 5.5.53-MariaDB key_buffer_size=67108864 read_buffer_size=2097152 max_used_connections=7 max_threads=258 thread_count=5 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1126889 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f645f211000 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f650b56fd60 thread_stack 0x48000 /usr/sbin/mysqld(my_print_stacktrace+0x2b)[0xa7833b] /usr/sbin/mysqld(handle_fatal_signal+0x398)[0x6d2b58] /lib64/libpthread.so.0(+0xf7e0)[0x7f650b2377e0] /usr/sbin/mysqld[0x945288] /usr/sbin/mysqld[0x88bf3e] /usr/sbin/mysqld[0x8c44f2] /usr/sbin/mysqld[0x8c6242] /usr/sbin/mysqld[0x8176b8] /usr/sbin/mysqld(_ZN7handler7ha_openEP5TABLEPKcij+0x3e)[0x6d687e] /usr/sbin/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x6d8)[0x633998] /usr/sbin/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0x7ac)[0x56170c] /usr/sbin/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x5a5)[0x5623d5] /usr/sbin/mysqld(_Z20open_and_lock_tablesP3THDP10TABLE_LISTbjP19Prelocking_strategy+0x44)[0x563044] /usr/sbin/mysqld[0x598418] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x34ac)[0x5a1b9c] /usr/sbin/mysqld[0x5a4474] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1bf8)[0x5a6948

] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x21b)[0x657f9b] /usr/sbin/mysqld(handle_one_connection+0x4c)[0x65801c] /lib64/libpthread.so.0(+0x7aa1)[0x7f650b22faa1] /lib64/libc.so.6(clone+0x6d)[0x7f6509b48aad] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f644cc1f018): is an invalid pointer Connection ID (thread ID): 758 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.

в 8.0 появился json_arrayagg()

непонятно почему эти козлы сразу не добавили поддержку по стандарту посгрес почему-то смог в json, а эти нет...

мм, дай подумать. Наверное потому, что стандарт SQL/JSON появился только в прошлом году. А всё, что посгрес делал до этого была самодеятельность

например, json_agg() — это не по стандарту. По стандарту будет json_arrayagg(). и в постгресе к стандарту приведут только в 11 версии

> InnoDB: Have you moved InnoDB .ibd files around without using the > InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? Honey, have you been moving .ibd files around?

ну ты думаешь из-за этого падает мария?

я думаю стоит для начала ответить на вопросы из лога

смотря на mysqld got signal 11, то signal 11 - это sigsegv, а в свою очередь уже сигнал, посылаемый процессу при попытке обращения к несуществующей памяти или обращения с нарушением прав доступа. SIGSEGV возникает только когда программа вылезает за пределы своей памяти. может попробовать обновиться до последней стабильной версии пятерки всё таки? просто после 5.5.53 (как у нас) вышло ещё 3 стабильных версии. 5.5.56 (2017-05-03) Stable 5.5.55 2017-04-13 Stable 5.5.54 2016-12-24 Stable

я думаю стоит для начала ответить на вопросы из лога

не понял тебя

а база падает в процессе работы или при старте?

при работе

стартует вообще нормально.

ну да, конечно она упоминиет мне каждый старт об > InnoDB: Have you moved InnoDB .ibd files around without using the > InnoDB: commands DISCARD TABLESPACE and IMPOR но как бы стартует со статусом succes

key_buffer_size=67108864 вы используете myisam ?

'vv

эмм

хотя это дэфолт скорее судя по размеру... в общем не суть

где такое можно глянуть?

ок )

поищите в хранимых процедурах on duplicate key по полям text и ему производным

а!

вот

key_buffer = 256M key_buffer_size=64M

не уверен что это оно, но мы недавно боролись с похожей проблемой на mysql, есть вариант что mariadb утащила этот баг к себе

поищите в хранимых процедурах on duplicate key по полям text и ему производным

погоди. я тут вообще с нуля к марии подошел. поэтому не понимаю о чем ты

что значит к себе?

база пустая?

у новой mysql 8 в отличии от 5.7-много нововведение и т.д? может быть есть статья на русском где можно обзорно прочесть и понять что и как?

база пустая?

ну тут как бы на хостинге проблема.

тут куча баз

на одном из сатов было вообще что сокетов не было

отсюда и пошел разбираться

оказалось в этот момент падала база

с логами которые ты видел выше

у новой mysql 8 в отличии от 5.7-много нововведение и т.д? может быть есть статья на русском где можно обзорно прочесть и понять что и как?

https://devconf.ru/data/devconf2017/ppt/293.pdf

Ого, спасибо! сейчас прочтёмс

рекурсивные запросы добавили

как в оракл-гуд

но я так понимаю всё это ещё не стабильно пока

нестабильно, да. пререлизы они для двух вещей: 1. можно пробовать и сообщать об ошибках и 2. можно начинать использовать в новых проектах — пока проект дорастёт до релиза, выйдет и стабильная версия

зачем они выпускают с обычной версией, а не RC-x?

у каждого релиза должен быть номер. то, что релиз не финальный обозначается суффиксом

вот например у меня сейчас: Version: '8.0.1-dmr-labs-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)

это не релиз

это кандидат

не надо проблемы с русской терминогией сюда мешать. всё, что выпускается (релизится) — это релиз с точки зрения английской мовы

и кандидат — это тоже на самом деле "кандидат релиза"

в прошлом была другая схема, когда пре-релизы обозначались типа 4.1-rc5. и это вызывало больше проблем в поддержке

"какая у вас версия?" — "4.1". а по факту "4.1-alpha123". с уникальными номерами всё проще

не надо проблемы с русской терминогией сюда мешать. всё, что выпускается (релизится) — это релиз с точки зрения английской мовы

при ем здесь русский? release candidate же

в прошлом была другая схема, когда пре-релизы обозначались типа 4.1-rc5. и это вызывало больше проблем в поддержке

для этого существует build number

обычно hash добавляют

и идентификация идёт по последним 4-м символам

как выличить базу ? InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. InnoDB: Unable to lock ./ibdata1, error: 11

убедиться, что не запущен другой процесс mysqld

да неее. 1000 раз рестартовал

ктобы его занял после рестарта

проверить права на директорию с .lock

тогда сделать stop

и проверить логи

там манипульнуть надо бы с файлами

170619 17:47:18 InnoDB: Could not open or create data files. 170619 17:47:18 InnoDB: If you tried to add new data files, and it failed here, 170619 17:47:18 InnoDB: you should now edit innodb_data_file_path in my.cnf back 170619 17:47:18 InnoDB: to what it was, and remove the new ibdata files InnoDB created 170619 17:47:18 InnoDB: in this failed attempt. InnoDB only wrote those files full of 170619 17:47:18 InnoDB: zeros, but did not yet use them in any way. But be careful: do not 170619 17:47:18 InnoDB: remove old data files which contain your precious data!

права на директорию с файлами базы нормальные?

lf

selinux выключен?

да

да

эт проверил уже