MySQL 5.1.36

[udomchok]

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-36.html

[เข้ม]

เมื่อสักครู่ได้ initial import เข้าไปเสร็จแล้ว

ทดสอบการใช้ Soundex Search ไม่มีปัญหาแล้วครับ

แต่มีปัญหาตอน replicate แทน

05/07/2552 15:44:11 xxx.xxx.xxx.xxx/hos  Can't connect to MySQL server on 'xxx.xxx.xxx.xxx' (10061)Socket error on connect. WSAGetLastError return 10061($274D) CLI>STAT-FRONT2 SQL>INSERT INTO incoth (vn,billdate,billtime,hn,incdate,inctime,income,paidst,rcpno,rcptamt,`user`,computer,finance_number,porder,discount,verify,pttype,hos_guid) VALUES ('520704194216','2009-07-04','19:42:16','000305720','2009-07-04','19:42:16','03','02',NULL,18,NULL,NULL,NULL,NULL,NULL,'N','71',NULL)
05/07/2552 15:44:20 xxx.xxx.xxx.xxx/hos  Lost connection to MySQL server during query CLI>STAT-FRONT1 SQL>delete from pttypehistory where hn='000095580' and  pttypeno='' and pttype not in ('0X','10','29','30','20','21','92','D1','D2')
05/07/2552 15:44:21 xxx.xxx.xxx.xxx/hos  Can't connect to MySQL server on 'xxx.xxx.xxx.xxx' (10061)Socket error on connect. WSAGetLastError return 10061($274D)


ผมกำลังตรวจสอบว่าเป็นที่ plugins FEDERATED ที่ผมใส่ไปหรือป่าว 

ท่านอื่น ๆ ได้ทดสอบกันบ้างหรือยัง
คุณตะนอย หายหน้าหายตาไปเลยนะครับ ...

[เข้ม]

หลังจากที่เอา plugins FEDERATED ออก แล้ว compile ใหม่ ก็ยังเหมือนเดิม
เข้าไปดูใน hostname.err

090705 16:13:23 mysqld_safe mysqld from pid file /usr/local/var/hostname.pid ended
090705 16:18:29 mysqld_safe Starting mysqld daemon with databases from /usr/local/var
090705 16:18:31  InnoDB: Started; log sequence number 3 918852314
090705 16:18:31 [Note] Event Scheduler: Loaded 0 events
090705 16:18:31 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.1.36-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

หลังจาก start mysql แล้วใช้งานได้ปกติ รวมถึง Soundex Search ด้วย

แต่หลังจากใช้ Replicate  ก็จะมี error เกิดขึ้น ดังนี้ (เผื่อ อ. ชัยพร จะแนะแนวทางการแก้ปัญหาครับ)

090705 16:29:18 [Warning] Statement may not be safe to log in statement format. Statement: ALTER TABLE general_log MODIFY COLUMN server_id INTEGER UNSIGNED NOT NULL
090705 16:29:18 [Warning] Statement may not be safe to log in statement format. Statement: ALTER TABLE slow_log MODIFY COLUMN server_id INTEGER UNSIGNED NOT NULL
090705 17:14:39  InnoDB: Assertion failure in thread 34387014512 in file row/row0mysql.c line 1534
InnoDB: Failing assertion: index->type & DICT_CLUSTERED
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.
090705 17:14:39 - 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=268435456
read_buffer_size=1048576
max_used_connections=1
max_threads=500
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1291159 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

090705 17:14:39 mysqld_safe mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 3 918853851
090705 17:14:40  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 3 919095169
090705 17:14:43  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 211966, file name ./mysql-bin.000001
090705 17:14:47  InnoDB: Started; log sequence number 3 919095169
090705 17:14:47 [Note] Recovering after a crash using mysql-bin
090705 17:14:47 [Note] Starting crash recovery...
090705 17:14:47 [Note] Crash recovery finished.
090705 17:14:47 [Note] Event Scheduler: Loaded 0 events
090705 17:14:47 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.1.36-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
090705 17:14:49  InnoDB: Assertion failure in thread 34387014512 in file row/row0mysql.c line 1534
InnoDB: Failing assertion: index->type & DICT_CLUSTERED
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.
090705 17:14:49 - 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.

[เข้ม]

จาก error ที่เกิดขึ้น
เป็น bug ตั้งแต่ 5.1.35 แล้วครับ

http://bugs.mysql.com/bug.php?id=45633

InnoDB: Assertion failure in thread 34387014512 in file row/row0mysql.c line 1534
Description:
After importing a dump, then starting replication, MySQL crashed shortly afterwards with
this error:

090620  9:02:29 [Note] Slave I/O thread: connected to master
'repl@127.0.0.1:3302',replication started in log 'db15-bin.006' at position 231881775
090620  9:06:43  InnoDB: Assertion failure in thread 60 in file row/row0mysql.c line 1534
InnoDB: Failing assertion: index->type & DICT_CLUSTERED

The server had the following unusual options set at the time:

innodb_doublewrite = 0
innodb_locks_unsafe_for_binlog = 1
innodb_flush_log_at_trx_commit = 0

The problem is repeatable; MySQL now crashed immediately whenever replication is started.

How to repeat:
Unknown
--------------------------------------------------------------------------------------------------------------------

http://en.wikipedia.org/wiki/Assertion_(computing)

แต่ผมยังไม่ได้ลองเปลี่ยน my.cnf ให้เป็น

innodb_doublewrite = 0                                          น่าจะเหมือนกันเกือบทุก รพ.
innodb_locks_unsafe_for_binlog = 1                       น่าจะเหมือนกันเกือบทุก รพ.
innodb_flush_log_at_trx_commit = 0                     ซึ่งแต่ละ รพ. น่าจะเป็น 1 หรือไม่ก็  2 

ตามนี้นะครับ
หลังจากที่พบปัญหาก็เลยถอยไปใช้ 5.1.30 เรียบร้อยแล้ว จึงมาค้นหาสาเหตุ 

ถ้าใครจะทดสอบ 5.1.36 ก็ขอให้ทดลองเปลี่ยนค่าใน my.cnf ให้เป็นดังข้างบนก็จะดี
จะได้รู้ว่าจะหายมั๊ย

[jdadmin1]

  รอพี่ tanoy ทดสอบครับ แต่ผมชอบตรงนี้จัง
How to repeat:
Unknown
มันตรงดี 55555
 

[atit]

รอพี่ tanoy ทดสอบครับ แต่ผมชอบตรงนี้จัง
How to repeat:
Unknown
มันตรงดี 55555
 

ขนาดท่าน JD ยังรอ ผมก็คงรอเหมือนกัน 

[manoi]

เป็น Bug ตัวนี้ครับ

http://bugs.mysql.com/bug.php?id=45357

รู้สึกว่าถูกแก้ไขแล้วใน 5.1.37 ครับ (ยังไม่ออกให้ download)

[มนตรี บอยรักยุ้ยคนเดียว]

จาก error ที่เกิดขึ้น
เป็น bug ตั้งแต่ 5.1.35 แล้วครับ

http://bugs.mysql.com/bug.php?id=45633

InnoDB: Assertion failure in thread 34387014512 in file row/row0mysql.c line 1534
Description:
After importing a dump, then starting replication, MySQL crashed shortly afterwards with
this error:

090620  9:02:29 [Note] Slave I/O thread: connected to master
'repl@127.0.0.1:3302',replication started in log 'db15-bin.006' at position 231881775
090620  9:06:43  InnoDB: Assertion failure in thread 60 in file row/row0mysql.c line 1534
InnoDB: Failing assertion: index->type & DICT_CLUSTERED

The server had the following unusual options set at the time:

innodb_doublewrite = 0
innodb_locks_unsafe_for_binlog = 1
innodb_flush_log_at_trx_commit = 0

The problem is repeatable; MySQL now crashed immediately whenever replication is started.

How to repeat:
Unknown
--------------------------------------------------------------------------------------------------------------------

http://en.wikipedia.org/wiki/Assertion_(computing)

แต่ผมยังไม่ได้ลองเปลี่ยน my.cnf ให้เป็น

innodb_doublewrite = 0                                          น่าจะเหมือนกันเกือบทุก รพ.
innodb_locks_unsafe_for_binlog = 1                       น่าจะเหมือนกันเกือบทุก รพ.
innodb_flush_log_at_trx_commit = 0                     ซึ่งแต่ละ รพ. น่าจะเป็น 1 หรือไม่ก็  2 

ตามนี้นะครับ
หลังจากที่พบปัญหาก็เลยถอยไปใช้ 5.1.30 เรียบร้อยแล้ว จึงมาค้นหาสาเหตุ 

ถ้าใครจะทดสอบ 5.1.36 ก็ขอให้ทดลองเปลี่ยนค่าใน my.cnf ให้เป็นดังข้างบนก็จะดี
จะได้รู้ว่าจะหายมั๊ย

ยังเป็นอยู่ครับ รอ 5.1.37 ดีกว่าครับ
ถึงจะแก้ my.cnf แล้ว ก็ยังไม่หาย

แต่ผมใช้ 5.1.30-2 percona

[yord]

ตอนนี้ใช้ 5.1.37 percona-log ทดสอบ ก็ยังมีปัญหาตอน run replicate อยู่ครับ ก็เลยไปปิด 3 บรรทัดข้างต้นก็ run replicate ได้ ไม่มีปัญหาครับ
#innodb_doublewrite = 0
#innodb_locks_unsafe_for_binlog = 1
#innodb_flush_log_at_trx_commit = 0