MySQL Community Server 5.5.13 has been released
Dear MySQL users, MySQL 5.5.13 is a new version of the 5.5 production release of the world's most popular open source database. MySQL 5.5.13 is recommended for use on production systems. MySQL 5.5 includes several high-impact enhancements to improve the performance and scalability of the MySQL Database, taking advantage of the latest multi-CPU and multi-core hardware and operating systems. In addition, with release 5.5, InnoDB is now the default storage engine for the MySQL Database, delivering ACID transactions, referential integrity and crash recovery by default. MySQL 5.5 also provides a number of additional enhancements including: - Significantly improved performance on Windows, with various Windows specific features and improvements - Higher availability, with new semi-synchronous replication and Replication Heart Beat - Improved usability, with Improved index and table partitioning, SIGNAL/RESIGNAL support and enhanced diagnostics, including a new Performance Schema monitoring capability. For a more complete look at what's new in MySQL 5.5, please see the following resources: MySQL 5.5 is GA, Interview with Tomas Ulin: http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html Documentation: http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html Whitepaper: What's New in MySQL 5.5: http://dev.mysql.com/why-mysql/white-papers/mysql-wp-whatsnew-mysql-55.php If you are running a MySQL production level system, we would like to direct your attention to MySQL Enterprise Edition, which includes the most comprehensive set of MySQL production, backup, monitoring, modeling, development, and administration tools so businesses can achieve the highest levels of MySQL performance, security and uptime. http://mysql.com/products/enterprise/ For information on installing MySQL 5.5.13 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.5/en/installing.html For upgrading from previous MySQL releases, please see the important upgrade considerations at: http://dev.mysql.com/doc/refman/5.5/en/upgrading.html MySQL Database 5.5 is available in source and binary form for a number of platforms from our download pages at: http://dev.mysql.com/downloads/mysql/ Not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://forge.mysql.com/wiki/Contributing The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.5. It may also be viewed online at: http://dev.mysql.com/doc/refman/5.5/en/news-5-5-13.html Enjoy! Changes in MySQL 5.5.13 : Note: Very old (MySQL 4.0) clients are not working temporarily due to a problem discovered after the release of MySQL 5.5.12. We are looking at fixing the problem. Bugs fixed: * InnoDB Storage Engine: If the server crashed while an XA transaction was prepared but not yet committed, the transaction could remain in the system after restart, and cause a subsequent shutdown to hang. (Bug #11766513, Bug #59641) * InnoDB Storage Engine: Similar problem to the foreign key error in bug #11831040 / 60196 / 60909, but with a different root cause and occurring on Mac OS X. With the setting lower_case_table_names=2, inserts into InnoDB tables covered by foreign key constraints could fail after a server restart. * Partitioning: The internal get_partition_set() function did not take into account the possibility that a key specification could be NULL in some cases. (Bug #12380149) * Partitioning: When executing a row-ordered retrieval index merge, the partitioning handler used memory from that allocated for the table, rather than that allocated to the query, causing table object memory not to be freed until the table was closed. (Bug #11766249, Bug #59316) * Replication: A spurious error malformed binlog: it does not contain any Format_description_log_event... was generated when mysqlbinlog was invoked using --base64-output=decode-row and --start-position=pos, where pos is a point in the binary log past the format description log event. However, there is nothing unsafe about not printing the format description log event, so the error has been removed for this case. (Bug #12354268) * Replication: Typographical errors appeared in the text of several replication error messages. (The word "position" was misspelled as "postion".) (Bug #11762616, Bug #55229) * Assignments to NEW.var_name within triggers, where var_name had a BLOB or TEXT type, were not properly handled and produced incorrect results
Re: Using where; Using temporary; Using filesort
> Is it ALWAYS possible to fabricate a query/schema in > such a way that MySQL ALWAYS uses the ideal No. Optimisation is better in 5.6 than in 5.0, though. Did you try adding multi-column indexes to cover the join and the order by clause? > 'Using where' extra -- you just have to keep at it? > Or is it the case that sometimes you're just S.O.L I don't know a general answer to that question. To figure out the answer in a particular case, I usually have to see the Create Table statements, see how the query performs with representative data, and experiment with various index setups. PB - On 5/31/2011 1:27 PM, Daevid Vincent wrote: I sent this Friday, but it never made it to the list?! -Original Message- From: Daevid Vincent [mailto:dae...@daevid.com] Sent: Friday, May 27, 2011 12:27 PM To: mysql@lists.mysql.com Subject: Using where; Using temporary; Using filesort I'm trying to optimize a query that doesn't seem all that complicated, however I can't seem to get it to not use a temp table and filesort. developer@vm_vz_daevid:~$ mysql --version mysql Ver 14.12 Distrib 5.0.92, for portbld-freebsd8.1 (amd64) using 5.2 EXPLAIN EXTENDED SELECT -- d.date_release, -- d.dvd_title, -- s.type, -- s.id_place, s.scene_id AS index_id, s.dvd_id FROM dvds AS d JOIN scenes_list AS s ON s.dvd_id = d.dvd_id AND d.status = 'ok' AND d.date_release != '-00-00' ORDER BY d.date_release DESC, d.dvd_title ASC, s.type ASC, s.id_place ASC; *** 1. row *** id: 1 select_type: SIMPLE table: d type: ref possible_keys: PRIMARY,date_release,status,status_release key: status_release key_len: 1 ref: const rows: 1976 Extra: Using where; Using temporary; Using filesort *** 2. row *** id: 1 select_type: SIMPLE table: s type: ref possible_keys: dvd_id_2,dvd_id key: dvd_id key_len: 4 ref: videoszcontent.d.dvd_id rows: 6 Extra: Using where 2 rows in set, 1 warning (0.00 sec) There are proper indexes on most every column in both tables (as you can see there). [a] the EXTENDED keyword doesn't seem to do anything different? I get the same columns and results??! [b] The commented out columns above I thought might help with the ORDER BY for some reason from my reading here: http://dev.mysql.com/doc/refman/5.0/en/order-by-optimization.html they did not. [c] lopping off the ORDER BY all together stops the "Using temporary; Using filesort" of course. Yeah! But now I'm left with a table of data in random order. Re-sorting it in PHP seems like an even bigger waste of cycles, when no doubt MySQL can sort hella-faster. [d] just doing " ORDER BY d.date_release DESC, d.dvd_title ASC; ", prevents the "using temporary" but still does "filesort" and again I'm in the boat of [c] I guess my question is this: Is it ALWAYS possible to fabricate a query/schema in such a way that MySQL ALWAYS uses the ideal 'Using where' extra -- you just have to keep at it? Or is it the case that sometimes you're just S.O.L. and no matter what, MySQL is going to give you a Cleveland Steamer? In other words, am I wasting my time trying to tweak my query and indexes here with the idea there's some magic incantation that will get this "right" or do I just have to accept it is what it is and it's not going to do any better. d. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Using where; Using temporary; Using filesort
I sent this Friday, but it never made it to the list?! -Original Message- From: Daevid Vincent [mailto:dae...@daevid.com] Sent: Friday, May 27, 2011 12:27 PM To: mysql@lists.mysql.com Subject: Using where; Using temporary; Using filesort I'm trying to optimize a query that doesn't seem all that complicated, however I can't seem to get it to not use a temp table and filesort. developer@vm_vz_daevid:~$ mysql --version mysql Ver 14.12 Distrib 5.0.92, for portbld-freebsd8.1 (amd64) using 5.2 EXPLAIN EXTENDED SELECT -- d.date_release, -- d.dvd_title, -- s.type, -- s.id_place, s.scene_id AS index_id, s.dvd_id FROM dvds AS d JOIN scenes_list AS s ON s.dvd_id = d.dvd_id AND d.status = 'ok' AND d.date_release != '-00-00' ORDER BY d.date_release DESC, d.dvd_title ASC, s.type ASC, s.id_place ASC; *** 1. row *** id: 1 select_type: SIMPLE table: d type: ref possible_keys: PRIMARY,date_release,status,status_release key: status_release key_len: 1 ref: const rows: 1976 Extra: Using where; Using temporary; Using filesort *** 2. row *** id: 1 select_type: SIMPLE table: s type: ref possible_keys: dvd_id_2,dvd_id key: dvd_id key_len: 4 ref: videoszcontent.d.dvd_id rows: 6 Extra: Using where 2 rows in set, 1 warning (0.00 sec) There are proper indexes on most every column in both tables (as you can see there). [a] the EXTENDED keyword doesn't seem to do anything different? I get the same columns and results??! [b] The commented out columns above I thought might help with the ORDER BY for some reason from my reading here: http://dev.mysql.com/doc/refman/5.0/en/order-by-optimization.html they did not. [c] lopping off the ORDER BY all together stops the "Using temporary; Using filesort" of course. Yeah! But now I'm left with a table of data in random order. Re-sorting it in PHP seems like an even bigger waste of cycles, when no doubt MySQL can sort hella-faster. [d] just doing " ORDER BY d.date_release DESC, d.dvd_title ASC; ", prevents the "using temporary" but still does "filesort" and again I'm in the boat of [c] I guess my question is this: Is it ALWAYS possible to fabricate a query/schema in such a way that MySQL ALWAYS uses the ideal 'Using where' extra -- you just have to keep at it? Or is it the case that sometimes you're just S.O.L. and no matter what, MySQL is going to give you a Cleveland Steamer? In other words, am I wasting my time trying to tweak my query and indexes here with the idea there's some magic incantation that will get this "right" or do I just have to accept it is what it is and it's not going to do any better. d. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Using where; Using temporary; Using filesort
s 2011/05/27 12:26 -0700, Daevid Vincent [a] the EXTENDED keyword doesn't seem to do anything different? I get the same columns and results??! "show warnings" 2011/05/27 12:26 -0700, Daevid Vincent In other words, am I wasting my time trying to tweak my query and indexes here with the idea there's some magic incantation that will get this "right" or do I just have to accept it is what it is and it's not going to do any better. Well, in general, of course there are problems for which no heuristic works--and indices _are_ heuristics. Houmuch real time does it take? I have two tables, one of addresses, another of the people living there s names, for the join wherof "explain extended" shows the same, and it does not bother me because it takes so little time. The output is only 1324 rows long. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MySQL server has gone away
Are you using connection pooling in your application? Regards, Chandru On 5/27/2011 11:05 AM, Claudio Nanni wrote: 'MySQL server has gone away' Can be a network problem, Just to increase complexity :) On May 26, 2011 11:03 PM, "Prabhat Kumar" wrote: I had experience with such type of error, It was due lack of resources available to MySql, max connections exceeds on the server. you can write a simple script which will grab and store output of 'show processlist' every min. and later you cna investigate the issue. On Wed, May 25, 2011 at 3:34 AM, Aveek Misra wrote: Nothing in the error log or the slow query log that suggests that the query size is too large or us taking too much time to execute. Thanks Aveek On May 25, 2011, at 3:53 PM, Rik Wasmus wrote: failed to execute " SELECT * FROM cluster_info WHERE cluster = ?": MySQL server has gone away The error "MySQL server has gone away" is the error from the db handle. Can anyone give me any pointers on why that happens? I looked up the documentation in MySQL docs and the most common reason seems to be that it happens if the query size is very large or if there is a timeout. None of them seems to be a probable cause. The "max_allowed_packet" on the server is 16 MB and as can be seen in the query above, the query is very small and nowhere near the size limit. We also have a timeout setting (wait_timeout) of 10 minutes and the above query for us cannot possibly take that amount of time. In any case, given the same query, it executes correctly 99% of time (so to speak). It fails intermittently with the above error. What possibly could be the reason? I also looked at the max connections on the server at that time (around ~80) and it is much less than the limit we have (limit is 1000). How can I extract more information when this happens? This error message sucks since it does not tell me what exactly happened. The server version is 5.1.45. Can you access the error log of the server? That can probably shed more light on the issue... -- Rik Wasmus -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=ave...@yahoo-inc.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=aim.prab...@gmail.com -- Best Regards, Prabhat Kumar MySQL DBA My Blog: http://adminlinux.blogspot.com My LinkedIn: http://www.linkedin.com/in/profileprabhat -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MySQL server has gone away
Try setting wait_timeout=36000 Regards, Chandru On 5/29/2011 11:13 PM, ars k wrote: Hi Aveek, I would like to suggest some points here: You could try increasing the max allowed packets to 128MB. Though you think 16MB is enough, increasing it is not going to affect the server. It is dynamic value, so you could revert back the changes if you feel so. Also make sure log_warnings=2 which will give more error messages in error log. This is the basic step for this error, if it is not working then we should check for other options then. Regards, Vinodh.k On Fri, May 27, 2011 at 11:05 AM, Claudio Nanniwrote: 'MySQL server has gone away' Can be a network problem, Just to increase complexity :) On May 26, 2011 11:03 PM, "Prabhat Kumar" wrote: I had experience with such type of error, It was due lack of resources available to MySql, max connections exceeds on the server. you can write a simple script which will grab and store output of 'show processlist' every min. and later you cna investigate the issue. On Wed, May 25, 2011 at 3:34 AM, Aveek Misra wrote: Nothing in the error log or the slow query log that suggests that the query size is too large or us taking too much time to execute. Thanks Aveek On May 25, 2011, at 3:53 PM, Rik Wasmus wrote: failed to execute " SELECT * FROM cluster_info WHERE cluster = ?": MySQL server has gone away The error "MySQL server has gone away" is the error from the db handle. Can anyone give me any pointers on why that happens? I looked up the documentation in MySQL docs and the most common reason seems to be that it happens if the query size is very large or if there is a timeout. None of them seems to be a probable cause. The "max_allowed_packet" on the server is 16 MB and as can be seen in the query above, the query is very small and nowhere near the size limit. We also have a timeout setting (wait_timeout) of 10 minutes and the above query for us cannot possibly take that amount of time. In any case, given the same query, it executes correctly 99% of time (so to speak). It fails intermittently with the above error. What possibly could be the reason? I also looked at the max connections on the server at that time (around ~80) and it is much less than the limit we have (limit is 1000). How can I extract more information when this happens? This error message sucks since it does not tell me what exactly happened. The server version is 5.1.45. Can you access the error log of the server? That can probably shed more light on the issue... -- Rik Wasmus -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=ave...@yahoo-inc.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=aim.prab...@gmail.com -- Best Regards, Prabhat Kumar MySQL DBA My Blog: http://adminlinux.blogspot.com My LinkedIn: http://www.linkedin.com/in/profileprabhat -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Using where; Using temporary; Using filesort
I'm trying to optimize a query that doesn't seem all that complicated, however I can't seem to get it to not use a temp table and filesort. developer@vm_vz_daevid:~$ mysql --version mysql Ver 14.12 Distrib 5.0.92, for portbld-freebsd8.1 (amd64) using 5.2 EXPLAIN EXTENDED SELECT -- d.date_release, -- d.dvd_title, -- s.type, -- s.id_place, s.scene_id AS index_id, s.dvd_id FROM dvds AS d JOIN scenes_list AS s ON s.dvd_id = d.dvd_id AND d.status = 'ok' AND d.date_release != '-00-00' ORDER BY d.date_release DESC, d.dvd_title ASC, s.type ASC, s.id_place ASC; *** 1. row *** id: 1 select_type: SIMPLE table: d type: ref possible_keys: PRIMARY,date_release,status,status_release key: status_release key_len: 1 ref: const rows: 1976 Extra: Using where; Using temporary; Using filesort *** 2. row *** id: 1 select_type: SIMPLE table: s type: ref possible_keys: dvd_id_2,dvd_id key: dvd_id key_len: 4 ref: videoszcontent.d.dvd_id rows: 6 Extra: Using where 2 rows in set, 1 warning (0.00 sec) There are proper indexes on most every column in both tables (as you can see there). [a] the EXTENDED keyword doesn't seem to do anything different? I get the same columns and results??! [b] The commented out columns above I thought might help with the ORDER BY for some reason from my reading here: http://dev.mysql.com/doc/refman/5.0/en/order-by-optimization.html they did not. [c] lopping off the ORDER BY all together stops the "Using temporary; Using filesort" of course. Yeah! But now I'm left with a table of data in random order. Re-sorting it in PHP seems like an even bigger waste of cycles, when no doubt MySQL can sort hella-faster. [d] just doing " ORDER BY d.date_release DESC, d.dvd_title ASC; ", prevents the "using temporary" but still does "filesort" and again I'm in the boat of [c] I guess my question is this: Is it ALWAYS possible to fabricate a query/schema in such a way that MySQL ALWAYS uses the ideal 'Using where' extra -- you just have to keep at it? Or is it the case that sometimes you're just S.O.L. and no matter what, MySQL is going to give you a Cleveland Steamer? In other words, am I wasting my time trying to tweak my query and indexes here with the idea there's some magic incantation that will get this "right" or do I just have to accept it is what it is and it's not going to do any better. d. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MySQL server has gone away
Hi Aveek, I would like to suggest some points here: You could try increasing the max allowed packets to 128MB. Though you think 16MB is enough, increasing it is not going to affect the server. It is dynamic value, so you could revert back the changes if you feel so. Also make sure log_warnings=2 which will give more error messages in error log. This is the basic step for this error, if it is not working then we should check for other options then. Regards, Vinodh.k On Fri, May 27, 2011 at 11:05 AM, Claudio Nanni wrote: > 'MySQL server has gone away' > Can be a network problem, > Just to increase complexity :) > On May 26, 2011 11:03 PM, "Prabhat Kumar" wrote: > > I had experience with such type of error, It was due lack of resources > > available to MySql, max connections exceeds on the server. > > you can write a simple script which will grab and store output of 'show > > processlist' every min. and later you cna investigate the issue. > > > > > > On Wed, May 25, 2011 at 3:34 AM, Aveek Misra > wrote: > > > >> Nothing in the error log or the slow query log that suggests that the > query > >> size is too large or us taking too much time to execute. > >> > >> Thanks > >> Aveek > >> > >> On May 25, 2011, at 3:53 PM, Rik Wasmus wrote: > >> > >> >> failed to execute " SELECT * FROM cluster_info WHERE cluster = > >> ?": > >> >> MySQL server has gone away > >> >> > >> >> The error "MySQL server has gone away" is the error from the db > handle. > >> Can > >> >> anyone give me any pointers on why that happens? I looked up the > >> >> documentation in MySQL docs and the most common reason seems to be > that > >> it > >> >> happens if the query size is very large or if there is a timeout. > None > >> of > >> >> them seems to be a probable cause. The "max_allowed_packet" on the > >> server > >> >> is 16 MB and as can be seen in the query above, the query is very > small > >> >> and nowhere near the size limit. We also have a timeout setting > >> >> (wait_timeout) of 10 minutes and the above query for us cannot > possibly > >> >> take that amount of time. In any case, given the same query, it > executes > >> >> correctly 99% of time (so to speak). It fails intermittently with the > >> >> above error. What possibly could be the reason? I also looked at the > max > >> >> connections on the server at that time (around ~80) and it is much > less > >> >> than the limit we have (limit is 1000). How can I extract more > >> information > >> >> when this happens? This error message sucks since it does not tell me > >> what > >> >> exactly happened. The server version is 5.1.45. > >> > > >> > Can you access the error log of the server? That can probably shed > more > >> light > >> > on the issue... > >> > -- > >> > Rik Wasmus > >> > > >> > -- > >> > MySQL General Mailing List > >> > For list archives: http://lists.mysql.com/mysql > >> > To unsubscribe: > >> http://lists.mysql.com/mysql?unsub=ave...@yahoo-inc.com > >> > > >> > >> > >> -- > >> MySQL General Mailing List > >> For list archives: http://lists.mysql.com/mysql > >> To unsubscribe: > >> http://lists.mysql.com/mysql?unsub=aim.prab...@gmail.com > >> > >> > > > > > > -- > > Best Regards, > > > > Prabhat Kumar > > MySQL DBA > > > > My Blog: http://adminlinux.blogspot.com > > My LinkedIn: http://www.linkedin.com/in/profileprabhat >
Repair Command takes too much time
Dear all, I have a table a_src in a mysql database as : 12K ac_src.frm 25G ac_src.MYD 60M ac_src.MYI Yesterday, near about 2 pm , I got the error : Error 1602 (23000) : Duplicate '6204567' for key 1 I solve this issue before by repairing the table but this time the data is very large. When I issue *repair table ac_src command *it take more than 20 hours to complete and still running. Accidently, server power got down & my command destroyed. Today I got stuck to it because I want to use that table & insert data in it. When I check my table it shows : mysql> check table hc_source; ++---+--+---+ | Table | Op| Msg_type | Msg_text | ++---+--+---+ | test_crawler.hc_source | check | error| Table './test_crawler/hc_source' is marked as crashed and last (automatic?) repair failed | ++---+--+---+ 1 row in set (0.00 sec) If I issue the repair command again again I know it can take morw than a day. I also attached my my.cnf file. I test the command myisamchk --silent --force --fast --update-state --key_buffer_size=512M --sort_buffer_size=512M --read_buffer_size=4M --write_buffer_size=4M /hrd2-2/myisam_data/test_crawler/hc_source.MYI and it is still running. Please help me to solve this problem and is there any simple solution to solve this. Thanks & best Regards, Adarsh Sharma # Example MySQL config file for medium systems. # # This is for a system with little memory (32M - 64M) where MySQL plays # an important part, or systems up to 128M where MySQL is used together with # other programs (such as a web server) # # You can copy this file to # /etc/my.cnf to set global options, # mysql-data-dir/my.cnf to set server-specific options (in this # installation this directory is /var/lib/mysql) or # ~/.my.cnf to set user-specific options. # # In this file, you can use all long options that a program supports. # If you want to know which options a program supports, run the program # with the "--help" option. [mysql.server] socket=/var/lib/mysql/mysql.sock # The following options will be passed to all MySQL clients [client] #password = your_password port= 3306 socket = /var/lib/mysql/mysql.sock # Here follows entries for some specific programs # The MySQL server [mysqld] user=mysql port= 3306 socket = /var/lib/mysql/mysql.sock log=/var/lib/mysql/server.log pid-file=/var/lib/mysql/server-5.pid skip-locking key_buffer_size=2048M table_cache=2048 net_buffer_length=8 read_buffer_size=512M read_rnd_buffer_size=64M myisam_sort_buffer_size=256M # The default character set that will be used when a new schema or table is # created and no character set is defined default-character-set=latin1 # The default storage engine that will be used when create new tables when default-storage-engine=myisam # back_log is the number of connections the operating system can keep in # the listen queue, before the MySQL connection manager thread has # processed them. If you have a very high connection rate and experience # "connection refused" errors, you might need to increase this value. # Check your OS documentation for the maximum value of this parameter. # Attempting to set back_log higher than your operating system limit # will have no effect. back_log = 50 # The maximum amount of concurrent sessions the MySQL server will # allow. One of these connections will be reserved for a user with # SUPER privileges to allow the administrator to login even if the # connection limit has been reached. max_connections = 100 # The maximum size of a query packet the server can handle as well as # maximum query size server can process (Important when working with # large BLOBs). enlarged dynamically, for each connection. max_allowed_packet = 32M # Maximum amount of errors allowed per host. If this limit is reached, # the host will be blocked from connecting to the MySQL server until # "FLUSH HOSTS" has been run or the server was restarted. Invalid # passwords and other errors during the connect phase result in # increasing this value. See the "Aborted_connects" status variable for # global counter. #max_connect_errors = 10 # The size of the cache to hold the SQL statements for the binary log # during a transaction. If you often use big, multi-statement # transactions you can increase this value to get more performance. All # statements from transactions are buffered in the binary log cache and # are being written to the binary log at once after the COMMIT. If the # transaction is larger than
