MySQL Replication Broken
Hi all, We have a pool of 8 MySQL servers where the first one is the master and the others 7 are slave. Yesterday we have a hard time where the server begin with too many lag ( 1 hour ) and then slaves start to fail with messages like this one thd=0x38f18130 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... Cannot determine thread, fp=0x418ac0a8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) New value of fp=0x38f18130 failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack tr ace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd-query at 0x3a4d2c13 = UPDATE t_items i, site_items_195_16 pc SET i.item_type = CASE pc.item_type WHEN '0' THEN 2 WHEN ' 1' THEN 2 WHEN '2' THEN 1 END, i.optional_field_6 = CASE pc.item_type WHEN '0' THEN '' WHEN '1' THEN 1 WHEN '2' THEN '' END , i.email = pc.email, i.optional_field_19 = pc.lang_id, i.optional_field_16 = pc.ip, i.optional_field_9 = (SELECT COUNT(*) FROM geodesic_auctions_bids ab WHERE ab.auction_id = i.item_id), i.title = pc.title, i.date = pc.date, i.description = pc.d escription, i.image = pc.image, i.price = pc.price, i.optional_field_8 = pc.deleted_type, i.optional_field_13 = pc.bloqued_ type WHERE i.item_id = pc.id AND i.item_id = 113347296 thd-thread_id=7 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. t is a temporal table. More strange was that Slave's failed with more or less 2 hours of difference. MySQL version is 5.0.x Any help is welcome, Thanks. -- Infrastructure Team OLX Inc. Buenos Aires - Argentina Phone : 54.11.4775.6696 Mobile : 54.911.50436059 Email: alejand...@olx.com
Re: INSERT DELAYED and logging
杨涛涛 *Stop top posting.* * * *thanks.* * * On Thu, Dec 23, 2010 at 12:16 AM, 杨涛涛 david.y...@actionsky.com wrote: Hi. I think if there are not some concurrency visitors, you should not use it. Otherwise, just put it. David Yeung, In China, Beijing. My First Blog:http://yueliangdao0608.cublog.cn My Second Blog:http://yueliangdao0608.blog.51cto.com My Msn: yueliangdao0...@gmail.com 2010/12/1 Wagner Bianchi wagnerbianch...@gmail.com I'll provide it to, bear with me, pls... Best regards. -- WB 2010/11/30 Johan De Meersman vegiv...@tuxera.be Interesting, but I feel the difference is rather small - could you rerun with, say, 50.000 queries ? Also, different concurrency levels (1, 100) might be interesting to see. Yes, I'm to lazy to do it myself, what did you think :-p On Tue, Nov 30, 2010 at 4:01 PM, Wagner Bianchi wagnerbianch...@gmail.com wrote: Friends, I did a benchmark regarding to this subject. Please, I am considering your comments. = http://wbianchi.wordpress.com/2010/11/30/insert-x-insert-delayed/ Best regards. -- WB 2010/11/30 Wagner Bianchi wagnerbianch...@gmail.com Maybe, the table in use must be a table that is inside cache now - SHOW OPEN TABLES, controlled by table_cache, I mean. Well, if the amount of data trasactioned is too small as a simple INSERT, you don't have to be worried, I suggest. If you partition the table, we must a benchmark to know the performance relation of a INSERT and compress data into Archive Storage Engine or the insertion data into a partitioned table. Best regards. -- WB 2010/11/30 Johan De Meersman vegiv...@tuxera.be I would assume that it's slower because it gets put on the delay thread anyway, and thus executes only whenever that thread gets some attention. I'm not sure wether there are other influencing factors. I should also think that not in use in this context means not locked against inserts, so the MyISAM insert-while-selecting at the end of a continguous table may well apply. No guarantees, though - I'm not that hot on this depth. On Tue, Nov 30, 2010 at 8:46 AM, WLGades wlga...@gmail.com wrote: What I'm confused by though, is this line. Note that INSERT DELAYED is slower than a normal INSERT if the table is not otherwise in use. What's the definition of in use? Does a logging table do that given that it's pretty much append-only/write-only? Waynn On Mon, Nov 29, 2010 at 10:19 PM, Johan De Meersman vegiv...@tuxera.bewrote: No, I think it's a good idea to do INSERT DELAYED here - it's only logging application, and it's generally more important to not slow down the application for that. It's only ever into a single table, so there's only going to be a single delay thread for it anyway. Archive tables are a good idea, agreed, but I suspect that inserts into that are going to be slower than into regular MyISAM because of the compression, so why not use that overhead to (slightly) speed up your end-user experience instead ? You can always partition the table based on the log date or whatever, if your table risks getting too big. On Tue, Nov 30, 2010 at 1:03 AM, Wagner Bianchi wagnerbianch...@gmail.com wrote: Well, analyze if you need to create an excessive overhead into the MySQL Server because a simple INSERT. What you must have a look is it: - How much data this connection is delivering to MySQL's handlers? - A word DELAYED in this case is making MySQL surfer? Perhaps, you are sophisticating something that do not need it. Besides it, analyzing your log table, I imagine this table can be an Archive table instead of MyISAM. Log tables or history tables can be controlled by Archive Storage Engine to have more compressed data. Although, Archive Storage Engine only supports SELECT and INSERT. Maybe, a good deal to you, get rid of you INSERT DELAYED: - ALTER TABLE tbl_name ENGINE = ARCHIVE; Best regards. -- WB 2010/11/29 WLGades wlga...@gmail.com I'm adding a table to our site that logs all page loads. In the past, when I built this, I used MyISAM and INSERT DELAYED. I went back to look at the documentation to see if I should still do this, and saw this (taken from http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html): Note that INSERT DELAYED is slower than a normal INSERT if the table is not otherwise in use. There is also the additional overhead for the server to handle a separate thread for each table for which there are delayed rows. This means that you should use INSERT DELAYED only when you
Re: Autostart not working for me in 5.5.8 version
You are right. In previous version init script have a default value, now is empty. mysql 5.1..53 - basedir=/usr/local/mysql mysql-5.5.8 - basedir=. Cheers. On Thu, Dec 16, 2010 at 12:42 AM, Yangontha Maung yangontha5...@yahoo.comwrote: Hi, I will answer my own question. I have to add a line in (/etc/my.cnf) as follows:- basedir=/usr/local/mysql I have installed mysql in /usr/local/mysql. But the same was done in previous versions and I do not need to add this. Anyway, now that it is working. rgds, --- On Thu, 12/16/10, Yangontha Maung yangontha5...@yahoo.com wrote: From: Yangontha Maung yangontha5...@yahoo.com Subject: Autostart not working for me in 5.5.8 version To: mysql@lists.mysql.com Date: Thursday, December 16, 2010, 11:14 AM Hi, Please help to set up the autostart of mysql when the Linux server starts. It is not working for me after installing to version 5.5.8. I have been using different versions of mysql for quite some time with different servers, Fedora versions. All these are working for autostart. But for this 5.5.8 I tried on two servers and both are not working for autostart. Please help. The following are my details:=- Installed on Fedora 12 Linux Previously mysql 5.1.48 is working and autorestart is also working. Now installed 5.5.8 Using manual starting is working /usr/local/mysql/bin/mysqld_safe But the auto start is not working. I have done this $ cp /usr/local/mysql/bin/support-files/mysql.server /etc/init.d/mysql $ chmod +x /etc/init.d/mysql $ ln –s /etc/init.d/mysql /etc/rc3.d/S99mysql $ ln –s /etc/init.d/mysql /etc/rc5.d/S99mysql $ ln –s /etc/init.d/mysql /etc/rc0.d/K01mysql thanks and rgds, -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=yangontha5...@yahoo.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=alejand...@olx.com -- Infrastructure Team OLX Inc. Buenos Aires - Argentina Phone : 54.11.4775.6696 Mobile : 54.911.50436059 Email: alejand...@olx.com
Re: Password Reset
SQL injection? Check Apache or whatever log files. On Thu, Dec 16, 2010 at 4:17 PM, Gary gp...@paulgdesigns.com wrote: I recieved a call from a client saying the web site did not work, turns out the database password was reset, and not by me. In looking in the DB after the PW was reset, I could find nothing out of place, although frankly I was not sure what to look for. Is this indicitive of an attack? Is this something to worry about? I had (or so I assumed) plenty of protections on the files, including one of the more popular anit-spam/injection attack systems. Any guidance on this would be appriciated. -- Gary __ Information from ESET Smart Security, version of virus signature database 5708 (20101216) __ The message was checked by ESET Smart Security. http://www.eset.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=alejand...@olx.com -- Infrastructure Team OLX Inc. Buenos Aires - Argentina Phone : 54.11.4775.6696 Mobile : 54.911.50436059 Email: alejand...@olx.com
