Can't start mysql/percona

    Hi,


    After migration from mariadb to percona, I have lots and lots of mysql stability problem.
    Now, mysql/percona don't want to start at all.
    I have follow lot and lot of tips on the web, without success.


    Here the log file when I'm starting mysql :

    Code
    1. Mar 5 10:54:24 paegu mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysqlMar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 0 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.Mar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).Mar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.Mar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] Plugin 'FEDERATED' is disabled.Mar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] InnoDB: Using atomics to ref count buffer pool pagesMar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] InnoDB: The InnoDB memory heap is disabledMar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtinsMar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] InnoDB: Memory barrier is not usedMar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] InnoDB: Compressed tables use zlib 1.2.7Mar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] InnoDB: Using Linux native AIOMar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 16022 [Note] InnoDB: Using CPU crc32 instructionsMar 5 10:54:24 paegu mysqld: 2015-03-05 10:54:24 7f953f26e720 InnoDB: Assertion failure in thread 140278986368800 in file ut0mem.cc line 105Mar 5 10:54:24 paegu mysqld: InnoDB: Failing assertion: ret || !assert_on_errorMar 5 10:54:24 paegu mysqld: InnoDB: We intentionally generate a memory trap.Mar 5 10:54:24 paegu mysqld: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.Mar 5 10:54:24 paegu mysqld: InnoDB: If you get repeated assertion failures or crashes, evenMar 5 10:54:24 paegu mysqld: InnoDB: immediately after the mysqld startup, there may beMar 5 10:54:24 paegu mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer toMar 5 10:54:24 paegu mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlMar 5 10:54:24 paegu mysqld: InnoDB: about forcing recovery.Mar 5 10:54:24 paegu mysqld: 09:54:24 UTC - mysqld got signal 6 ;Mar 5 10:54:24 paegu mysqld: This could be because you hit a bug. It is also possible that this binaryMar 5 10:54:24 paegu mysqld: or one of the libraries it was linked against is corrupt, improperly built,Mar 5 10:54:24 paegu mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.Mar 5 10:54:24 paegu mysqld: We will try our best to scrape up some info that will hopefully helpMar 5 10:54:24 paegu mysqld: diagnose the problem, but since we have already crashed, Mar 5 10:54:24 paegu mysqld: something is definitely wrong and this may fail.Mar 5 10:54:24 paegu mysqld: Please help us make Percona Server better by reporting anyMar 5 10:54:24 paegu mysqld: bugs at http://bugs.percona.com/Mar 5 10:54:24 paegu mysqld: Mar 5 10:54:24 paegu mysqld: key_buffer_size=16777216Mar 5 10:54:24 paegu mysqld: read_buffer_size=131072Mar 5 10:54:24 paegu mysqld: max_used_connections=0Mar 5 10:54:24 paegu mysqld: max_threads=153Mar 5 10:54:24 paegu mysqld: thread_count=0Mar 5 10:54:24 paegu mysqld: connection_count=0Mar 5 10:54:24 paegu mysqld: It is possible that mysqld could use up to Mar 5 10:54:24 paegu mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 77372 K bytes of memoryMar 5 10:54:24 paegu mysqld: Hope that's ok; if not, decrease some variables in the equation.Mar 5 10:54:24 paegu mysqld: Mar 5 10:54:24 paegu mysqld: Thread pointer: 0x0Mar 5 10:54:24 paegu mysqld: Attempting backtrace. You can use the following information to find outMar 5 10:54:24 paegu mysqld: where mysqld died. If you see no messages after this, something wentMar 5 10:54:24 paegu mysqld: terribly wrong...Mar 5 10:54:24 paegu mysqld: stack_bottom = 0 thread_stack 0x30000Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x8af7de]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x36c)[0x66847c]Mar 5 10:54:24 paegu mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7f953ee540a0]Mar 5 10:54:24 paegu mysqld: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f953d08d165]Mar 5 10:54:24 paegu mysqld: /lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7f953d0903e0]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld[0x9ba520]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld[0xa5462b]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld[0xa3a56e]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld[0x995dd7]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld[0x8e0879]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x5c4af8]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld[0x6e9dc4]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x7b1)[0x6eb4e1]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x7a7)[0x5bc1c7]Mar 5 10:54:24 paegu mysqld: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f953d079ead]Mar 5 10:54:24 paegu mysqld: /usr/sbin/mysqld[0x5b25ad]Mar 5 10:54:24 paegu mysqld: You may download the Percona Server operations manual by visitingMar 5 10:54:24 paegu mysqld: http://www.percona.com/software/percona-server/. You may find informationMar 5 10:54:24 paegu mysqld: in the manual which will help you identify the cause of the crash.Mar 5 10:54:24 paegu mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid endedMar 5 10:54:35 paegu /etc/init.d/mysql[16153]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted inMar 5 10:54:35 paegu /etc/init.d/mysql[16153]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failedMar 5 10:54:35 paegu /etc/init.d/mysql[16153]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'Mar 5 10:54:35 paegu /etc/init.d/mysql[16153]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!Mar 5 10:54:35 paegu /etc/init.d/mysql[16153]:


    Here my /etc/mysql/my.cnf :

    Code
    1. [client]port = 3306socket = /var/run/mysqld/mysqld.sock# Here is entries for some specific programs# The following values assume you have at least 32M ram# This was formally known as [safe_mysqld]. Both versions are currently parsed.[mysqld_safe]socket = /var/run/mysqld/mysqld.socknice = 0[mysqld]## * Basic Settings#user = mysqlpid-file = /var/run/mysqld/mysqld.pidsocket = /var/run/mysqld/mysqld.sockport = 3306basedir = /usrdatadir = /var/lib/mysqltmpdir = /tmplc-messages-dir = /usr/share/mysqlskip-external-locking## Instead of skip-networking the default is now to listen only on# localhost which is more compatible and is not less secure.bind-address = 127.0.0.1## * Fine Tuning#key_buffer = 16Mmax_allowed_packet = 16Mthread_stack = 192Kthread_cache_size = 8# This replaces the startup script and checks MyISAM tables if needed# the first time they are touchedmyisam-recover = BACKUP#max_connections = 100#table_cache = 64#thread_concurrency = 10## * Query Cache Configuration#query_cache_limit = 1Mquery_cache_size = 16Mexpire_logs_days = 10max_binlog_size = 100M#binlog_do_db = include_database_name#binlog_ignore_db = include_database_name## * InnoDB## InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.# Read the manual for more InnoDB related options. There are many!## * Security Features## Read the manual, too, if you want chroot!# chroot = /var/lib/mysql/## For generating SSL certificates I recommend the OpenSSL GUI "tinyca".## ssl-ca=/etc/mysql/cacert.pem# ssl-cert=/etc/mysql/server-cert.pem# ssl-key=/etc/mysql/server-key.pem[mysqldump]quickquote-namesmax_allowed_packet = 16M[mysql]#no-auto-rehash # faster start of mysql but no tab completition[isamchk]key_buffer = 16M## * IMPORTANT: Additional settings that can override those from this file!# The files must end with '.cnf', otherwise they'll be ignored.#!includedir /etc/mysql/conf.d/


    I also can't run the i-mscp installer with success. It's stop with this error :


    I really want to understand what's going wrong because another server under i-mscp 1.2.x has the same symptom.


    My configuration :
    i-mscp 1.2.x (recently updated)
    Debian 7.8
    1Go RAM
    512Mo swap

    Hello @Phinous


    Re-add my SSH key and give me the IP again.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    Re ;


    This is because mysql is out of memory (not enough memory available on your server.) Anyway, some other issue are there and you should also look for any subject related to mariadb 10 to percona 5.6 upgrade such as http://www.fromdual.com/migrat…ercona-server-and-mariadb.


    I've stopped some other services and restarted mysql which is running now.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    Thanks a lot for the look nuxwin.
    Anyway, I'm a little bit disapointed by the memory need since I have upgrade from i-mscp 1.1.x to 1.2.x
    Before, my two servers could run with 480Mo of RAM, and now they need at least 1400Mo tu run properly for the same resources hosted !


    I can understand than there is no link between this memory need and the upgrade because i-mscp is just an automated set of scripts in front of usual packages, but I really asking myself about that change...
    Maybe I have to tune something (I tried a lot of things without success...), I tried to use percona, mariadb and mysql...
    I'm pretty sure than it's only a small tuning somewhere... but where ? I have investigate for 4 hours this morning because asking help !


    Anyway, I don't know if there is a way to downgrade i-mscp to 1.1.x...
    I know it's not a viable solution, but IMHO it could be a good test to be sure the problem comes from elsewhere !

    @Phinous


    I'll not start a debate here but what I can say is: Nothing in i-MSCP 1.2.x explain your problem ;)


    BTW: On your virtual server ( with 1Gib ram ) you're running:

    • Mail service ( imap, smtp, pop3 servers )
    • Apache2 with PHP applications run as CGI programs using Fcgid
    • Proftpd
    • Mysql
    • munin
    • fail2ban
    • ...


    Do you really think that 1Go ram is sufficient? I doubts ;) If when you try to start MySQL server ( here percona ), the needed memory cannot be allocated, it will fail miserably like now ;) You should tune your mysql server and also give your PHP applications less memory.


    So yes, you can tune your server but you must know how ;)


    About percona, a tool is available here: https://tools.percona.com/wizard
    For PHP, you must lower the memory limit and so on in each php.ini file and restart Apache2. You can do the same thing for the panel php.ini file and once done, restart the imscp_panel service.
    You should also lower both FcgidMaxProcesses and FcgidMaxProcessesPerClass in the fcgid_imscp.conf file and restart Apache.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support