Hrm, if there is a risk of crashing the server I'll have to plan some
maintenance time to do it. I'll work on that tonight.
On Apr 12, 2010, at 7:58 PM, Yasufumi Kinoshita wrote:
> Hello Laine,
> I still need more information to specify the situation.
>
> Could you confirm the output of following commands before the
> building index?
> Or, are the commands also cause crushing?
>
> <index information of mysqld>
>> show indexes from [table_name];
>
> <index information of InnoDB>
>> select * from information_schema.INNODB_INDEX_STATS where
>> table_name like '%[table_name]%';
>
> --
> Index add causes innodb assertion failure
> https://bugs.launchpad.net/bugs/560347
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Percona XtraDB Storage Engine for MySQL: New
>
> Bug description:
> Since moving from 5.1.36 xtradb 5 to 5.1.43, xtradb 9.1, we have had
> regular mysql segfaults during index builds. This doesn't happen
> every time, but has happened 3 different times on 2 different
> servers. (identical server builds).
>
> Each time, rebuilding the table via dump from a replica is required
> to fix the problem.
>
>
> 100409 9:20:56 [ERROR] Table la_management_console/
> type1_session_memberships contains fewer indexes inside InnoDB than
> are defined in the MySQL .frm file. Have you mixed up .frm files
> from different installations? See http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting.html
>
> 100409 9:24:12 InnoDB: Assertion failure in thread 1269074256 in
> file handler/ha_innodb.cc line 7113
> InnoDB: Failing assertion: index
> 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.1/en/forcing-recovery.html
> InnoDB: about forcing recovery.
> 100409 9:24:12 - 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.
> 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.
>
> key_buffer_size=134217728
> read_buffer_size=10485760
> max_used_connections=29
> max_threads=2000
> threads_connected=19
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads
> = 53400306 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> thd: 0xa6051f0
> 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 = 0x4ba48100 thread_stack 0x20000
> /usr/local/mysql/libexec/mysqld(my_print_stacktrace+0x35)[0x8a2315]
> /usr/local/mysql/libexec/mysqld(handle_segfault+0x322)[0x5ca022]
> /lib64/libpthread.so.0[0x7f38937057d0]
> /lib64/libc.so.6(gsignal+0x35)[0x7f3892af1095]
> /lib64/libc.so.6(abort+0x110)[0x7f3892af2af0]
> /usr/local/mysql/libexec/mysqld[0x76af9c]
> /usr/local/mysql/libexec/mysqld[0x6ae323]
> /usr/local/mysql/libexec/mysqld[0x6aec30]
> /usr/local/mysql/libexec/mysqld[0x6aef07]
> /usr/local/mysql/libexec/
> mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyyb
> +0xdfe)[0x6b803e]
> /usr/local/mysql/libexec/mysqld[0x647bc0]
> /usr/local/mysql/libexec/mysqld(_ZN4JOIN8optimizeEv+0x5a1)[0x648601]
> /usr/local/mysql/libexec/
> mysqld
> (_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex
> +0xab)[0x651a2b]
> /usr/local/mysql/libexec/
> mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x169)
> [0x652459]
> /usr/local/mysql/libexec/mysqld[0x5d53fc]
> /usr/local/mysql/libexec/mysqld(_Z21mysql_execute_commandP3THD+0xcd3)
> [0x5d9f73]
> /usr/local/mysql/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x39b)
> [0x5e131b]
> /usr/local/mysql/libexec/
> mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x403)
> [0x5e1723]
> /usr/local/mysql/libexec/mysqld(_Z10do_commandP3THD+0x120)[0x5e2970]
> /usr/local/mysql/libexec/mysqld(handle_one_connection+0x690)[0x5d2ba0]
> /lib64/libpthread.so.0[0x7f38936fd3f7]
> /lib64/libc.so.6(clone+0x6d)[0x7f3892b96b4d]
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0x7f36f13488b0 is an invalid pointer
> thd->thread_id=2628
> thd->killed=NOT_KILLED
> 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.
> 100409 09:24:13 mysqld_safe Number of processes running now: 0
>
>
> Linux 2.6.24-25-generic #1 SMP Tue Oct 20 06:49:12 UTC 2009 x86_64
> GNU/Linux
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=8.04
> DISTRIB_CODENAME=hardy
> DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"
>
> Server version: 5.1.43-log Percona SQL Server (GPL), XtraDB 9.1,
> Revision 59
>
>
> [mysqld]
> basedir=/usr/local/mysql
> key_buffer = 128M
> max_allowed_packet = 16M
> thread_stack = 128K
> thread_cache_size = 2048
> table_cache = 4096
> sort_buffer = 16M
> join_buffer_size = 2M
> read_buffer_size = 10M
> read_rnd_buffer_size = 16M
> max_connections = 2000
> max_allowed_packet = 32M
> max_connect_errors = 99999999
> log_slow_queries = /var/log/mysql/mysql-slow.log
> long_query_time = 1
> log-queries-not-using-indexes
> log_slave_updates
> log_bin = /var/log/mysql/mysql-bin.log
> expire_logs_days = 10
> max_binlog_size = 100M
> innodb_additional_mem_pool_size = 64M
> innodb_buffer_pool_size = 5G
> innodb_file_per_table = 1
> innodb_thread_concurrency = 0
> innodb_commit_concurrency = 1
> innodb_thread_sleep_delay = 0
> innodb_flush_log_at_trx_commit = 0
> innodb_log_buffer_size = 12M
> innodb_log_file_size = 256M
> innodb_log_files_in_group = 2
> innodb_max_dirty_pages_pct = 25
> innodb_lock_wait_timeout = 120
> innodb_flush_method=O_DIRECT
> innodb_ibuf_accel_rate = 200
> innodb_overwrite_relay_log_info=true
> sync_binlog=1
> innodb_file_format = barracuda
> innodb_io_capacity = 4000
> innodb_support_xa = false
> innodb_read_io_threads = 8
> innodb_write_io_threads = 8
> innodb_ibuf_active_contract = 1
> innodb_adaptive_flushing = false
> innodb_adaptive_checkpoint = estimate
> server-id = 116
> auto_increment_increment = 2
> auto_increment_offset = 1
> user=mysql
> group=mysql
> [mysql.server]
> user=mysql
> basedir=/usr/local/mysql
> datadir=/var/lib/mysql
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/percona-xtradb/+bug/560347/+subscribe
Hrm, if there is a risk of crashing the server I'll have to plan some
maintenance time to do it. I'll work on that tonight.
On Apr 12, 2010, at 7:58 PM, Yasufumi Kinoshita wrote:
> Hello Laine, schema. INNODB_ INDEX_STATS where /bugs.launchpad .net/bugs/ 560347 console/ memberships contains fewer indexes inside InnoDB than dev.mysql. com/doc/ refman/ 5.1/en/ innodb- troubleshooting .html ha_innodb. cc line 7113 bugs.mysql. com. dev.mysql. com/doc/ refman/ 5.1/en/ forcing- recovery. html size=134217728 size=10485760 connections= 29 connected= 19 size)*max_ threads mysql/libexec/ mysqld( my_print_ stacktrace+ 0x35)[0x8a2315] mysql/libexec/ mysqld( handle_ segfault+ 0x322)[ 0x5ca022] libpthread. so.0[0x7f389370 57d0] libc.so. 6(gsignal+ 0x35)[0x7f3892a f1095] libc.so. 6(abort+ 0x110)[ 0x7f3892af2af0] mysql/libexec/ mysqld[ 0x76af9c] mysql/libexec/ mysqld[ 0x6ae323] mysql/libexec/ mysqld[ 0x6aec30] mysql/libexec/ mysqld[ 0x6aef07] mysql/libexec/ _ZN10SQL_ SELECT17test_ quick_selectEP3 THD6BitmapILj64 EEyyb mysql/libexec/ mysqld[ 0x647bc0] mysql/libexec/ mysqld( _ZN4JOIN8optimi zeEv+0x5a1) [0x648601] mysql/libexec/ selectP3THDPPP4 ItemP10TABLE_ LISTjR4ListIS1_ ES2_jP8st_ orderSB_ S2_SB_yP13selec t_resultP18st_ select_ lex_unitP13st_ select_ lex mysql/libexec/ _Z13handle_ selectP3THDP6st _lexP13select_ resultm+ 0x169) mysql/libexec/ mysqld[ 0x5d53fc] mysql/libexec/ mysqld( _Z21mysql_ execute_ commandP3THD+ 0xcd3) mysql/libexec/ mysqld( _Z11mysql_ parseP3THDPKcjP S2_+0x39b) mysql/libexec/ _Z16dispatch_ command19enum_ server_ commandP3THDPcj +0x403) mysql/libexec/ mysqld( _Z10do_ commandP3THD+ 0x120)[ 0x5e2970] mysql/libexec/ mysqld( handle_ one_connection+ 0x690)[ 0x5d2ba0] libpthread. so.0[0x7f38936f d3f7] libc.so. 6(clone+ 0x6d)[0x7f3892b 96b4d] NOT_KILLED dev.mysql. com/doc/ mysql/en/ crashing. html RELEASE= 8.04 CODENAME= hardy DESCRIPTION= "Ubuntu 8.04.3 LTS" /usr/local/ mysql buffer_ size = 16M mysql/mysql- slow.log not-using- indexes mysql/mysql- bin.log additional_ mem_pool_ size = 64M buffer_ pool_size = 5G file_per_ table = 1 thread_ concurrency = 0 commit_ concurrency = 1 thread_ sleep_delay = 0 flush_log_ at_trx_ commit = 0 log_buffer_ size = 12M log_file_ size = 256M log_files_ in_group = 2 max_dirty_ pages_pct = 25 lock_wait_ timeout = 120 flush_method= O_DIRECT ibuf_accel_ rate = 200 overwrite_ relay_log_ info=true read_io_ threads = 8 write_io_ threads = 8 ibuf_active_ contract = 1 adaptive_ flushing = false adaptive_ checkpoint = estimate increment = 2 offset = 1 /usr/local/ mysql /var/lib/ mysql /bugs.launchpad .net/percona- xtradb/ +bug/560347/ +subscribe
> I still need more information to specify the situation.
>
> Could you confirm the output of following commands before the
> building index?
> Or, are the commands also cause crushing?
>
> <index information of mysqld>
>> show indexes from [table_name];
>
> <index information of InnoDB>
>> select * from information_
>> table_name like '%[table_name]%';
>
> --
> Index add causes innodb assertion failure
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Percona XtraDB Storage Engine for MySQL: New
>
> Bug description:
> Since moving from 5.1.36 xtradb 5 to 5.1.43, xtradb 9.1, we have had
> regular mysql segfaults during index builds. This doesn't happen
> every time, but has happened 3 different times on 2 different
> servers. (identical server builds).
>
> Each time, rebuilding the table via dump from a replica is required
> to fix the problem.
>
>
> 100409 9:20:56 [ERROR] Table la_management_
> type1_session_
> are defined in the MySQL .frm file. Have you mixed up .frm files
> from different installations? See http://
>
> 100409 9:24:12 InnoDB: Assertion failure in thread 1269074256 in
> file handler/
> InnoDB: Failing assertion: index
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://
> 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://
> InnoDB: about forcing recovery.
> 100409 9:24:12 - 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.
> 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.
>
> key_buffer_
> read_buffer_
> max_used_
> max_threads=2000
> threads_
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_
> = 53400306 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> thd: 0xa6051f0
> 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 = 0x4ba48100 thread_stack 0x20000
> /usr/local/
> /usr/local/
> /lib64/
> /lib64/
> /lib64/
> /usr/local/
> /usr/local/
> /usr/local/
> /usr/local/
> /usr/local/
> mysqld(
> +0xdfe)[0x6b803e]
> /usr/local/
> /usr/local/
> /usr/local/
> mysqld
> (_Z12mysql_
> +0xab)[0x651a2b]
> /usr/local/
> mysqld(
> [0x652459]
> /usr/local/
> /usr/local/
> [0x5d9f73]
> /usr/local/
> [0x5e131b]
> /usr/local/
> mysqld(
> [0x5e1723]
> /usr/local/
> /usr/local/
> /lib64/
> /lib64/
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0x7f36f13488b0 is an invalid pointer
> thd->thread_id=2628
> thd->killed=
> The manual page at http://
> contains
> information that should help you find out what is causing the crash.
> 100409 09:24:13 mysqld_safe Number of processes running now: 0
>
>
> Linux 2.6.24-25-generic #1 SMP Tue Oct 20 06:49:12 UTC 2009 x86_64
> GNU/Linux
> DISTRIB_ID=Ubuntu
> DISTRIB_
> DISTRIB_
> DISTRIB_
>
> Server version: 5.1.43-log Percona SQL Server (GPL), XtraDB 9.1,
> Revision 59
>
>
> [mysqld]
> basedir=
> key_buffer = 128M
> max_allowed_packet = 16M
> thread_stack = 128K
> thread_cache_size = 2048
> table_cache = 4096
> sort_buffer = 16M
> join_buffer_size = 2M
> read_buffer_size = 10M
> read_rnd_
> max_connections = 2000
> max_allowed_packet = 32M
> max_connect_errors = 99999999
> log_slow_queries = /var/log/
> long_query_time = 1
> log-queries-
> log_slave_updates
> log_bin = /var/log/
> expire_logs_days = 10
> max_binlog_size = 100M
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> sync_binlog=1
> innodb_file_format = barracuda
> innodb_io_capacity = 4000
> innodb_support_xa = false
> innodb_
> innodb_
> innodb_
> innodb_
> innodb_
> server-id = 116
> auto_increment_
> auto_increment_
> user=mysql
> group=mysql
> [mysql.server]
> user=mysql
> basedir=
> datadir=
>
> To unsubscribe from this bug, go to:
> https:/