GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

Percona 5.6.19-67.0 fresh installation do not apply /etc/my.cnf

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Percona 5.6.19-67.0 fresh installation do not apply /etc/my.cnf

    As the title says my fresh installation of percona server is not reading my old /etc/my.cnf from mysql 5.5 .

    I have tried to put the file also in /etc/mysql/my.cnf, /usr/etc/my.cnf and ~/.my.cnf, but still not being applied after restart percona server.

    I check it using mysql > show variables like '%timeout%'; and values are always different from the ones i apply in my.cnf .

    The default settings of percona server don't allow me to perform some heavy tasks in database in my development server, therefore i need to apply different settings.

    mysql console output:
    Code:
    mysql>
    Welcome to the MySQL monitor.  Commands end with ; or \g.
    Your MySQL connection id is 544
    Server version: 5.6.19-67.0 Percona Server (GPL), Release 67.0, Revision 618
    
    Copyright (c) 2009-2014 Percona LLC and/or its affiliates
    Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.
    
    Oracle is a registered trademark of Oracle Corporation and/or its
    affiliates. Other names may be trademarks of their respective
    owners.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    show variables like "%timeout%";
    +-----------------------------+----------+
    | Variable_name               | Value    |
    +-----------------------------+----------+
    | connect_timeout             | 10       |
    | delayed_insert_timeout      | 300      |
    | have_statement_timeout      | YES      |
    | innodb_flush_log_at_timeout | 1        |
    | innodb_lock_wait_timeout    | 50       |
    | innodb_rollback_on_timeout  | OFF      |
    | interactive_timeout         | 50       |
    | lock_wait_timeout           | 31536000 |
    | net_read_timeout            | 30       |
    | net_write_timeout           | 60       |
    | rpl_stop_slave_timeout      | 31536000 |
    | slave_net_timeout           | 3600     |
    | thread_pool_idle_timeout    | 60       |
    | wait_timeout                | 50       |
    +-----------------------------+----------+
    14 rows in set (0.00 sec)

    /etc/my.cnf
    Code:
    [client]
    port=3306
    socket=/var/run/mysqld/mysqld.sock
    
    [mysqld_safe]
    socket=/var/run/mysqld/mysqld.sock
    
    [mysqld]
    user=mysql
    pid-file=/var/run/mysqld/mysqld.pid
    socket=/var/run/mysqld/mysqld.sock
    port=3306
    basedir=/usr
    datadir=/var/lib/mysql
    tmpdir=/tmp
    lc-messages-dir=/usr/share/mysql
    log_error=/var/log/mysql/error.log
    max_connections=200
    max_user_connections=30
    wait_timeout=300
    interactive_timeout=100
    long_query_time=60
    innodb_file_per_table
    
    !includedir /etc/mysql/conf.d

    /etc/mysql/conf.d/mysqld_safe_syslog.cnf
    Code:
    [mysqld_safe]
    syslog

  • #2
    I found the reason, not the solution here https://blog.mozilla.org/it/2012/04/...-wait_timeout/

    Why.... because checking for variables in mysql console is a wrong approach, at least for the setting wait_timeout.

    This happens also in oracle mysql.

    It seems that the myslq developers where not in a good day when they decided to mix the value of interactive_timeout with wait_timeout, as this is not an intuitive behavior to be expected.

    As i always like to say... living and learning

    Comment

    Working...
    X