Re: How to get all known bugs on specified mysql version?
don't use GTID is my suggestion :) 2014-07-07 7:42 GMT+08:00 娄帅 louis.hust...@gmail.com: Hi, all, I want to use MySQL 5.6.18 in production, so i want to get all known bugs on this version. Now i check the bugfix section in MySQL 5.6.19 and above version. Am i doing the right thing? Or Do you have a better method? Any input will be appreciated! -- Phone: +86 1868061 Email Gtalk: yloui...@gmail.com Personal Blog: http://www.vmcd.org
Re: Doubts tuning MySQL Percona Server 5.5
Hi, I was checking MySQL performance ... Sometimes my database could be working slow. I have some queries that spend 9-10 seconds updating some columns by primary key. I'm not sure if is a data base problem ... Moreover, I have checked tuning scripts and appear these variables. Good sentence! Thanks in advance. Regards, Antonio.
Re: How to get all known bugs on specified mysql version?
Why do not use GTID? Just curious...WB 2014-07-07 3:18 GMT-03:00 louis liu yloui...@gmail.com: don't use GTID is my suggestion :) 2014-07-07 7:42 GMT+08:00 娄帅 louis.hust...@gmail.com: Hi, all, I want to use MySQL 5.6.18 in production, so i want to get all known bugs on this version. Now i check the bugfix section in MySQL 5.6.19 and above version. Am i doing the right thing? Or Do you have a better method? Any input will be appreciated! -- Phone: +86 1868061 Email Gtalk: yloui...@gmail.com Personal Blog: http://www.vmcd.org
Re: How to get all known bugs on specified mysql version?
Am 07.07.2014 12:37, schrieb wagnerbianchi.com: Why do not use GTID? Just curious...WB just read the changelogs and endless count of bugreports it's a new feature and it works as buggy as replication years ago where you had the rebuild the slave all the time and maybe still if temporary tables and memory tables are part of the game - i had a reason to switch to normal tables with hash-names and remove them finally since that didn't break replication all the time 2014-07-07 3:18 GMT-03:00 louis liu yloui...@gmail.com: don't use GTID is my suggestion :) 2014-07-07 7:42 GMT+08:00 娄帅 louis.hust...@gmail.com: Hi, all, I want to use MySQL 5.6.18 in production, so i want to get all known bugs on this version. Now i check the bugfix section in MySQL 5.6.19 and above version. Am i doing the right thing? Or Do you have a better method? Any input will be appreciated! signature.asc Description: OpenPGP digital signature
Re: Doubts tuning MySQL Percona Server 5.5
- Original Message - From: Antonio Fernández Pérez antoniofernan...@fabergroup.es Subject: Re: Doubts tuning MySQL Percona Server 5.5 I was checking MySQL performance ... Sometimes my database could be working slow. I have some queries that spend 9-10 seconds updating some columns by primary key. I'm not sure if is a data base problem ... If the same query is sometimes OK and sometimes not, that's usually a consequence of varying load, or possibly rushes on various resources. Those are typically things that are, honestly, rather hard to figure out over email. The Percona boys have some rather good blog posts and tutorials that may be of interest. Do an explain of the naughty queries, if the explain comes up good, there's going to be an underlying cause. Moreover, I have checked tuning scripts and appear these variables. Tuning scripts are a good first look, but they're just stupid little things, they have no idea about the baseline performance for your environment. They also mostly don't look at performance over time, they just see an average from start of server until now - which is obviously mostly useless if you have several months of uptime. InnoDB log waits is 103; innodb_log_buffer_size is 8M -- Maybe the next best value could be 16M? 8M is not a bad value, but you'd have to have a look at how much logging you push to disk, and how fast that goes. Incidentally, as this is a theme in your questions, you don't always have to double the values :-) Table cache hit rate is 12%; Open_tables is 627; table_open_cache is 1024 Well, the table cache isn't full, so I suspect not. Keep an eye on Opened_tables - that tells you how many tables have been opened since service start, so it shouldn't increase dramatically once it's up to speed. Key buffer hit rate is 93.7%; I have some queries that not using indexes .. I keep coming back to the same question: why do you think that's a bad number? :-) Have a look at wether you can add indexes or otherwise optimise those queries, but it's perfectly possible and acceptable if that's not possible - maybe it's possible to offload the hard queries to a separate slave? Optimise in function of your environment. Only your can define what constitutes acceptable performance in your environment. join_buffer_size is 4M -- Next best value? Maybe 8M and then check it again? I strongly recommend not touching those at all - oftentimes, those kind of variables either don't do quite what you think at first glance, or are part of a more complex system. Specifically for the join_buffer_size, note that: * it is the MINIMUM that gets allocated, wether or not it's needed * it is not allocated per-session, but PER-JOIN, so a single complex query may allocate several. So, that means that even the smallest query that needs a join buffer will allocate 4M, and while it depends on your environment, it's very probably that you have more small queries than large ones :-) Keep it small by default, and if you know a query is going to need big buffers, you can still set it larger as a session variable when you need it. The best advice I can give you is to set up Munin, Cacti or another tool to monitor server status and performance over time; that way you will get a baseline for what's normal; see any behaviour that deviates from the baseline, *and* can meaningfully see the impact over time of any changes you make. /johan -- Unhappiness is discouraged and will be corrected with kitten pictures.
Re: How to get all known bugs on specified mysql version?
Hello, On 7/6/2014 7:42 PM, 娄帅 wrote: Hi, all, I want to use MySQL 5.6.18 in production, so i want to get all known bugs on this version. Now i check the bugfix section in MySQL 5.6.19 and above version. Am i doing the right thing? Or Do you have a better method? Any input will be appreciated! The easiest way to see which bugs are pending is to actually search the bugs database, http://bugs.mysql.com Here is one example search you can perform. Note, many of these bugs (such as bug #49728) are low-impact edge-cases that are prioritized lower than other more important high-impact bugs. Our development teams have limited resources. We triage and prioritize what they can work on based on how severe the bug is, how often is may be encountered, and how easy it may be to work around. http://bugs.mysql.com/search.php?search_for=status[]=Activeseverity=limit=Allorder_by=idcmd=displayphpver=5.5os=0os_details=bug_age=0tags=similar=target=last_updated=0defect_class=allworkaround_viability=allimpact=allfix_risk=allfix_effort=alltriageneeded= Anyone can join the fight! Start by submitting an OCA (Oracle Contributor's Agreement). http://www.oracle.com/technetwork/community/oca-486395.html If you have any questions about the OCA, please contact the MySQL community team. http://www.mysql.com/about/contact/?topic=community Then, any patches you provide can be analyzed, possibly improved, and potentially merged into the actual source code. For some recent examples, see: http://www.tocker.ca/2014/06/09/mysql-5-6-19-community-release-notes.html -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
