Here you are:

[client]
port        = 3306
socket        = /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.sock
nice        = 0

[mysqld]
#
# * Basic Settings
#
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket        = /var/run/mysqld/mysqld.sock
port        = 3306
basedir        = /usr
datadir        = /mnt/mysql_tmpfs/mysql
tmpdir        = /tmp
lc-messages-dir    = /usr/share/mysql
skip-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_size         = 512M
max_allowed_packet      = 32M
thread_stack            = 2M
thread_cache_size       = 8

# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options  = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit = 10M
query_cache_size        = 512M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries    = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for 
replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id        = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_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!

# don't fsync the logs (for speed)
innodb_flush_log_at_trx_commit = 0

# * 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]
quick
quote-names
max_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/

On Monday, August 1, 2016 at 11:52:07 PM UTC-4, gilberto dos santos alves 
wrote:
>
> hi. please post your /etc/my.ini  (or your equiv. mysql ini config file).
>
> 2016-08-01 21:05 GMT-03:00 Tim Graham <[email protected] <javascript:>>:
>
>> Sometimes the MySQL 5.7.13 builds on Ubuntu 16.04 are failing with "Lost 
>> connection to MySQL server during query" because the MySQL server restarts 
>> during the tests. I wonder if anyone has an idea about how to solve this. 
>> Looking through the MySQL error log, I think this is the root cause:
>>
>> 2016-08-01T23:02:56.636617Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has 
>> lasted > 600 seconds. We intentionally crash the server because it appears 
>> to be hung.
>> 2016-08-01 23:02:56 0x7f5fb75d8700  InnoDB: Assertion failure in thread 
>> 140049074980608 in file ut0ut.cc line 920
>> InnoDB: We intentionally generate a memory trap.
>> InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
>> InnoDB: If you get repeated assertion failures or crashes, even
>> InnoDB: immediately after the mysqld startup, there may be
>> InnoDB: corruption in the InnoDB tablespace. Please refer to
>> InnoDB: 
>> http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
>> InnoDB: about forcing recovery.
>> 23:02:56 UTC - mysqld got signal 6 ;
>> 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.
>> Attempting to collect some information that could help diagnose the 
>> problem.
>> As this is a crash and something is definitely wrong, the information
>> collection process might fail.
>>
>> key_buffer_size=536870912
>> read_buffer_size=131072
>> max_used_connections=4
>> max_threads=151
>> thread_count=4
>> connection_count=4
>> It is possible that mysqld could use up to 
>> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 
>> 584285 K  bytes of memory
>> Hope that's ok; if not, decrease some variables in the equation.
>>
>> Thread pointer: 0x0
>> 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 = 0 thread_stack 0x200000
>> /usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe7bdab]
>> /usr/sbin/mysqld(handle_fatal_signal+0x489)[0x783759]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x7f60131dc3d0]
>> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f6012596418]
>> /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f601259801a]
>> /usr/sbin/mysqld[0x759764]
>> /usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0x145)[0x110c905]
>> /usr/sbin/mysqld(srv_error_monitor_thread+0xe2d)[0x10aa34d]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f60131d26fa]
>> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6012667b5d]
>> 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.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3f787f25-2e3f-49b1-b6a3-7a3411e70a9b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/3f787f25-2e3f-49b1-b6a3-7a3411e70a9b%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> gilberto dos santos alves
> +55(11)9-8646-5049
> sao paulo - sp - brasil
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1e174d51-5a77-4ef7-b95c-9cfbd4c294e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to