There is quite a lot of confusion in the description of these variables, in official documentation of MySQL.
According to it, max_binlog_cache_size means,
If a transaction requires more than this many bytes of memory, the
server generates a Multi-statement transaction required more than
'max_binlog_cache_size' bytes of storage error.
max_binlog_cache_size sets the size for the transaction cache only
and binlog_cache_size means,
The size of the cache to hold changes to the binary log during a
transaction.
binlog_cache_size sets the size for the transaction cache only
On reading the documentation, I observed there is no difference among these two. There is also something very confusing in the documentation like,
In MySQL 5.7, the visibility to sessions of max_binlog_cache_size
matches that of the binlog_cache_size system variable; in other words,
changing its value effects only new sessions that are started after
the value is changed.
When I query the server variables it shows both. I have a MySQL 5.6 and a MySQL 5.7. All I need to know is, which variable I should consider and configure for which server.
binlog_cache_size for MySQL 5.6 and max_binlog_cache_size for MySQL 5.7??
There are additional confusing variables max_binlog_stmt_cache_size and binlog_stmt_cache_size, related to these.
Both variables can be configured in both versions, they have different meaning. Definitions in the manual and in the help are confusing; here is a much better explanation: http://dev.mysql.com/doc/refman/5.6/en/binary-log.html
binlog_cache_size defines the maximum amount of memory that the buffer can use. If transaction grows above this value, it uses a temporary disk file. Please note that the buffer is allocated per connection.
max_binlog_cache_size defines the maximum total size of a transaction. If the transaction grows above this value, it fails.
Below is a simple demonstration of the difference.
Setup:
MariaDB [test]> select ##binlog_cache_size, ##max_binlog_cache_size, ##binlog_format;
+---------------------+-------------------------+-----------------+
| ##binlog_cache_size | ##max_binlog_cache_size | ##binlog_format |
+---------------------+-------------------------+-----------------+
| 32768 | 65536 | ROW |
+---------------------+-------------------------+-----------------+
1 row in set (0.01 sec)
MariaDB [test]> show create table t1 \G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`a` text
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
1. Transaction size is below ##binlog_cache_size
(transaction succeeds, uses the cache, does not use the disk)
MariaDB [test]> flush status;
Query OK, 0 rows affected (0.00 sec)
MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)
MariaDB [test]> insert into t1 values (repeat('a',20000));
Query OK, 1 row affected (0.01 sec)
MariaDB [test]> insert into t1 values (repeat('a',10000));
Query OK, 1 row affected (0.04 sec)
MariaDB [test]> commit;
Query OK, 0 rows affected (0.05 sec)
MariaDB [test]> show status like 'Binlog_cache%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 1 |
+-----------------------+-------+
2 rows in set (0.01 sec)
2. Transaction size is above ##binlog_cache_size, but below ##max_binlog_cache_size
(transaction uses the cache, and the cache uses the disk)
MariaDB [test]> flush status;
Query OK, 0 rows affected (0.00 sec)
MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)
MariaDB [test]> insert into t1 values (repeat('a',20000));
Query OK, 1 row affected (0.10 sec)
MariaDB [test]> insert into t1 values (repeat('a',20000));
Query OK, 1 row affected (0.10 sec)
MariaDB [test]> commit;
Query OK, 0 rows affected (0.03 sec)
MariaDB [test]> show status like 'Binlog_cache%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Binlog_cache_disk_use | 1 |
| Binlog_cache_use | 1 |
+-----------------------+-------+
2 rows in set (0.01 sec)
3. Transaction size exceeds ##max_binlog_cache_size
(transaction fails)
MariaDB [test]> flush status;
Query OK, 0 rows affected (0.00 sec)
MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)
MariaDB [test]> insert into t1 values (repeat('a',20000));
Query OK, 1 row affected (0.12 sec)
MariaDB [test]> insert into t1 values (repeat('a',20000));
Query OK, 1 row affected (0.15 sec)
MariaDB [test]> insert into t1 values (repeat('a',20000));
Query OK, 1 row affected (0.12 sec)
MariaDB [test]> insert into t1 values (repeat('a',20000));
ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again
So, if your transactions are big, but you don't have too many connections, you might want to increase ##binlog_cache_size to avoid excessive disk writes.
If you have many concurrent connections, you should be careful to avoid connections trying to allocate too much memory for the caches simultaneously.
If you want to make sure that transactions don't grow too big, you might want to limit ##max_binlog_cache_size.
##binlog_stmt_cache_size and ##max_binlog_stmt_cache_size should work in a similar way, the difference is that %binlog_cache% values are for transactional updates, and %binlog_stmt_cache% for non-transactional updates.
While experimenting, please note that the values are not 100% precise, there are some hidden subtleties with initially allocated sizes. It shouldn't matter for practical purposes, but can be confusing when you play with low values.
Why will this not update 501 records? What's wrong with my query?
MariaDB [contacts]> UPDATE history h, phone_corrections t SET h.contact = t.new_nmbr WHERE h.contact = t.old_nmbr;
Query OK, 0 rows affected (0.03 sec)
Rows matched: 501 Changed: 0 Warnings: 0
MariaDB [contacts]>
FIXED! There were several records where the wrong_nmbr field was the same value as the right_nmbr field. Sorry for the post.
I'm getting warnings when updating a table but the warnings are not showing. Through tedious and lengthy trial-and-error, the cause of the warnings has been tracked down to the INNER JOIN. I need a better way to debug a warning.
Setup is OK. I know warnings are on because MySQL command prompt was started with option '--show-warnings' and warnings are turned on warnings with '\W':
mysql> \W
Show warnings enabled.
mysql> show variables like '%warn%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_warnings | 0 |
| sql_warnings | ON |
| warning_count | 0 |
+---------------+-------+
3 rows in set (0.01 sec)
To make sure warnings were on, I forced a truncating warning on a VARCHAR(255) field:
mysql> UPDATE course
-> SET course.transcript_title = 'Field transcript_title is VARCHAR(255). This is over 255 characters to force truncating warning. Field transcript_title is VARCHAR(255). This is over 255 characters to force truncating warning. Field transcript_title is VARCHAR(255). This is over 255 characters to force truncating warning.'
-> WHERE course.title LIKE '%SLP%'
-> AND course.year = 2008
-> AND course.gid = 35;
Query OK, 104 rows affected, 104 warnings (0.19 sec)
Rows matched: 104 Changed: 104 Warnings: 104
Warning (Code 1265): Data truncated for column 'transcript_title' at row 1
Warning (Code 1265): Data truncated for column 'transcript_title' at row 2
.... etc.
I want to get the warning from this type of query:
mysql> UPDATE course
-> INNER JOIN group_info ON course.gid = group_info.id
-> SET course.description = 'Foo.'
-> WHERE course.title LIKE '%SLP%'
-> AND course.year = 2008 AND group_info.id = 35;
Query OK, 0 rows affected (0.02 sec)
Rows matched: 104 Changed: 0 Warnings: 104
mysql> SHOW WARNINGS;
Empty set (0.00 sec)
From trial and error, I know the error is from having the INNER JOIN clause. If I remove the INNER JOIN and directly use the gid (group id) field in the course table, then no warnings:
mysql> UPDATE course
-> SET course.description = 'Bar.'
-> WHERE course.title LIKE '%SLP%'
-> AND course.year = 2008
-> AND course.gid = 35;
Query OK, 104 rows affected (0.01 sec)
Rows matched: 104 Changed: 104 Warnings: 0
But I need the INNER JOIN clause because what I really want to do is use the more friendly 'name' field in the joined 'group_info' table:
UPDATE course
INNER JOIN group_info ON course.gid = group_info.id
SET course.description = 'Foo.'
WHERE course.title LIKE '%SLP%'
AND course.year = 2008
AND group_info.name = 'One-to-One Meeting Time';
I've been googling, reading, and debugging the warning for over 1 hour. I've searched for answers or explanations for why this would not show warnings but no luck.
How do I get warnings to show for the INNER JOIN type of UPDATE?
This does not seem to work
mysql> SET PASSWORD FOR juser201411#localhost= PASSWORD(".6,y:C2a");
ERROR 1133 (42000): Can't find any matching row in the user table
After that I tried manually adding from mysql.user
mysql> update mysql.user set password=('.6,y:C2a') where User='juser201411' and Host='localhost';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> select User from mysql.user;+------+
| User |
+------+
| root |
| root |
+------+
2 rows in set (0.00 sec)
centos 6.5 x64
Try to use the CREATE USER syntax. For more information see MySQL doc
CREATE USER 'juser201411'#'localhost' IDENTIFIED BY PASSWORD '.6,y:C2a';
For me I had put the line into a txt editor to fill it out and some of my single quotes had gotten converted to smart quotes...hard to see, but obvious once you do(!)
I notice a very weird problem in my code. I am inserting a value of 128 but in my database it says 127.
I'd like to look at the mysql general/query logs however i dont ever see any log files produce no matter what i do. I tried -l , -l with an absolute path and --general_log_file. No luck. I also used mysqladmin flush-logs. Still nothing
Are you using a signed TINYINT datatype by any chance?
CREATE TABLE my_table (id TINYINT);
Query OK, 0 rows affected (0.03 sec)
INSERT INTO my_table VALUES (128);
Query OK, 1 row affected, 1 warning (0.00 sec)
SELECT * FROM my_table;
+------+
| id |
+------+
| 127 |
+------+
1 row in set (0.00 sec)