mysqlbinlog

Fun with Bugs #56 – On Some Public Bugs Fixed in MySQL 5.7.20

While MySQL 8.0.x hardly has much impact on my regular work, recent MySQL 5.7.20 release is something to check carefully. MySQL 5.7 is widely used in production, as a base for Percona Server 5.7, some features may be merged into MariaDB 10.x etc. So, here is my review of some community reported bugs that were fixed in recently released MySQL 5.7.20, based on the release notes.Usually I start with InnoDB bug fixes, but in 5.7.20 several related fixes were made only to bugs reported internally. So, this time I have to start with partitioning:
Bug #86255 – First one to write about, and the bug report is private… Second one (Bug #76418) is also private. All we have is this:
“Partitioning: In certain cases when fetching heap records a partition ID could be set to zero. (Bug #86255, Bug #26034430)””Partitioning: Queries involving NULL were not always handled correctly on tables that were partitioned by LIST. (Bug #76418, Bug #20748521)”
That’s all, folks. I fail to understand why bugs with such a description can stay private after they are fixed. I have to admit: I do not get it. Moreover, I am not going even to try any longer. Lists with one item look stupid, but hiding such bugs is not much better, IMHO.Lucky I am, there were several bug fixes related to replication:

Bug #85352 – “Replication regression with RBR and partitioned tables”. This regression bug (comparing to 5.5.x) was reported by Juan Arruti and immediately verified by Umesh Shastry. I do not know why it is listed as InnoDB in the release notes, as it hardly can be about native InnoDB partitioning, based on versions affected.

Bug #86224 – “mysqlrplsync errors out because slave is using –super-read-only option”. It was reported by Richard Morris and verified by Bogdan Kecman.

Bug #84731 – “Group Replication: mysql client connections hang during group replication start”, was reported by Kenny Gryp and verified by Umesh Shastry. Another bug reported by Kenny was also fixed in 5.7.20, Bug #84798 – “Group Replication can use some verbosity in the error log”.

Bug #86250 – “thd->ha_data[ht_arg->slot].ha_ptr_backup == __null || (thd->is_binlog_applier()”. This debug assertion was reported by Roel Van de Paar and verified by Umesh Shastry. 

Bug #85639 – “XA transactions are ‘unsafe’ for RPL using SBR”. It was reported by João Gramacho.

Bug #86288 – “mysqlbinlog read-from-remote-server not honoring rewrite_db filtering”, was reported by Julie Hergert.
Other bug fixes not to miss are:

Bug #85622 – “5.6: wrong results with materialization, views”. It was reported by Shane Bester. Even though it was initially stated that only 5.6 is affected, release notes say there was a fix for 5.7.20 and even 8.0.3.

Bug #82992 – “Some warnings appear in dump from mysqldump”. This funny bug was found by Nong LO and verified by Sinisa Milivojevic.

Bug #81714 – “mysqldump get_view_structure does not free MYSQL_RES in one error path”. Thisbug was reported by Laurynas Biveinis, but it was noticed and patched by Yura Sorokin, also from Percona.

Bug #83950 – “LOAD DATA INFILE fails with an escape character followed by a multi-byte one”, was reported by yours truly and verified by Umesh Shastry. Unfortunately the bug report itself does NOT say explicitly what versions had got the fix.

Bug #79596 – “If client killed after ROLLBACK TO SAVEPOINT previous stmts committed”. This regression and potential data corruption bug was reported by Sveta Smirnova, verified by Umesh Shastry and studied at the source code level by Zhai Weixiang. Nice to see it fixed!
That’s all, few build and packaging related bugs aside.This was my very last attempt to do a detailed review of bug reports from MySQL Community based on official Release Notes. With private bugs and very few fixes for things coming from the public bugs database in general, it seems to make zero sense now to continue these. Authors of patches contributed are properly mentioned by Oracle, and we all know who verify community bug reports… One Twitter message would be enough to fit everything I have to say, and any real details should better be checked in git commits.It’s time to get back to the roots of this series and maybe write about bugs just opened, bugs not properly handled or just funny ones. I think it helped a lot back in 2013 to make MySQL 5.6 a release that was commonly accepted as a “good one”. It’s not fun any more and not much useful to report Oracle achievements in public bugs fixing, so I’d better switch to their problems.

Fun with Bugs #46 – On Some Bugs I’ve Reported During the Year of 2016

It’s time to summarize the year of 2016. As a kind of a weird summary, in this post I’d like to share a list of MySQL bug reports I’ve created in 2016 that are still remaining “Verified” today:Bug #79831 – “Unexpected error message on crash-safe slave with max_relay_log_size set”. According to Umesh this is not repeatable with 5.7. The fact that I’ve reported the bug on January 4 probably means I was working at that time. I should not repeat this mistake again next year.Bug #80067 – “Index on BIT column is NOT used when column name only is used in WHERE clause”. People say the same problem happens with INT and, what may be even less expected, BOOLEAN columns.Bug #80424 – “EXPLAIN output depends on binlog_format setting”. Who could expect that?Bug #80619 – “Allow slave to filter replication events based on GTID”. In this feature request I’ve suggested to implement filtering by GTID pattern, so that we can skip all events originating from specific master on some slave in a complex replication chain.Bug #82127 – “Deadlock with 3 concurrent DELETEs by UNIQUE key”. It’s clear that manual is not even close to explaining how the locks are really set “by design” in this weird case. See comments in MDEV-10962 for some explanations. Nobody from Oracle event tried to really explain how things are designed to work.Bug #82212 – “mysqlbinlog can produce events larger than max_allowed_packet for mysql”. This happens for encoded row-based events. There should be some way to take this overhead into account while creating binary log, IMHO.Bug #83024 – “Internals manual does not explain COM_SLEEP in details”. One day you’ll see Sleep for some 17 seconds logged into the slow query log, and may start to wonder why…Bug #83248 – “Partition pruning is not working with LEFT JOIN”. You may find some interesting related ideas in MDEV-10946.Bug #83640 – “Locks set by DELETE statement on already deleted record”. This case shows that design of locking in InnoDB does produce really weird outcomes sometimes. This is not about “missing manual”, this is about extra lock set that is absolutely NOT needed (a gap X lock on a record in the secondary unique index is set when the same transaction transaction already has the next key lock on it). As a side note, I keep finding, explaining and reporting weird or undocumented details in InnoDB locking for years, still my talk about InnoDB locks was not accepted by Oracle once again for OOW in 2016. What do I know about the subject and who even cares about those locks… Bug #83708 – “uint expression is used for the value that is passed as my_off_t for DDL log”. I was really shocked by this finding. I assumed that all uint vs unsigned long long improper casts are already found. It seems I was mistaking.Bug #83912 – “Time spent sleeping before entering InnoDB is not measured/reported separately”. The use case that led me to reporting this bug is way more interesting than the fact that some wait is not instrumented in performance_schema. You may see more related bug reports from me next year.Bug #83950 – “LOAD DATA INFILE fails with an escape character followed by a multi-byte one”. This single bug (and related bugs and stories) were original topic for issue #46 of my “Fun With Bugs” series. I was not able to write everything I want properly over last 3 weeks, but trust me: it’s a great story, of “Let’s Make America Great Again” style. With the goal for LOAD DATA to behave exactly as INSERT when wrong utf8 data are inserted, Oracle changed the way LOAD DATA works back and forth, with the last change (back) happened in 5.7.17: “Incompatible Change: A change made in MySQL 5.7.8 for handling of multibyte character sets by LOAD DATA was reverted due to the replication incompatibility (Bug #24487120, Bug #82641)”I just can not keep up with all the related fun people have in replication environments thanks to these ongoing changes… It’s incredible.Bug #84004 – “Manual misses details on MDL locks set and released for online ALTER TABLE”. Nothing new: locks in MySQL are not properly/completely documented, metadata locks included. yes, they are documented better now, after 11+ years of my continuous efforts (of a kind), but we are “not there yet”. I am still waiting for a job offer to join MySQL Documentation Team, by the way :)Bug #84173 – “mysqld_safe –no-defaults & silently does NOT work any more”. Recent MySQL 5.7.17 release had not only given us new Group Replication plugin and introduced incompatible changes. In a hope to fix security issues it comes with pure regression – for the first time in last 11 years mysqld_safe –no-defaults stopped working for me! By the way, mysqld_safe is still NOT safe in a sense that 5.7.17 tried to enforce, and one day (really soon) you will find out why.Bug #84185 – “Not all “Statements writing to a table with an auto-increment…” are unsafe”. If you do something like DELETE FROM `table` WHERE some_col IN (SELECT some_id FROM `other_table`) where `table` has auto_increment column, why should anyone care about it? We do not generate the value, we delete rows… This bug report was actually created by Hartmut Holzgraefe and test case comes from Elena Stepanova (see MDEV-10170). I want to take this opportunity to thank them and other colleagues from MariaDB for their hard work and cooperation during the year of 2016. Thanks to Umesh (who processed most of my bug reports),  Sinisa Milivojevic and Miguel Solorzano for their verifications of my bug reports this year.In conclusion I should say that, no matter how pointless you may consider this activity, I still suggest you to report each and every problem that you have with MySQL and can not understand after reading the manual, as a public MySQL bug. Now, re-read my 4 years old post on this topic and have a Happy and Fruitful New Year 2017!

Identifying useful info from MySQL row-based binary logs

As a MySQL DBA/consultant, it is part of my job to decode the MySQL binary logs – and there are a number of reasons for doing that. In this post, I’ll explain how you can get the important information about your write workload using MySQL row-based binary logs and a simple awk script.First, it is important to understand that row-based binary logs contain the actual changes done by a query. For example, if I run a delete query against a table, the binary log will contain the rows that were deleted. MySQL provides the mysqlbinlog utility to decode the events stored in MySQL binary logs. You can read more about mysqlbinlog in detail in the reference manual here.The following example illustrates how mysqlbinlog displays row events that specify data modifications. These correspond to events with the WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, and DELETE_ROWS_EVENT type codes.We will use following options of mysqlbinlog. –base64-output=decode-rows –verbose, -v –start-datetime=”datetime” –stop-datetime=”datetime”We have a server running with row based binary logging.mysql> show variables like ‘%binlog_format%’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| binlog_format | ROW |
+—————+——-+
1 row in set (0.00 sec)We created a test table and executed the following sequence of statements under a transaction.use test;
CREATE TABLE t
(
id INT NOT NULL,
name VARCHAR(20) NOT NULL,
date DATE NULL
) ENGINE = InnoDB;
START TRANSACTION;
INSERT INTO t VALUES(1, ‘apple’, NULL);
UPDATE t SET name = ‘pear’, date = ‘2009-01-01′ WHERE id = 1;
DELETE FROM t WHERE id = 1;
COMMIT;Now let’s see how it is represented in binary logs.# mysqlbinlog –base64-output=decode-rows -vv –start-datetime=”2015-01-12 21:40:00″ –stop-datetime=”2015-01-12 21:45:00″ mysqld-bin.000023
/*!*/;
# at 295
#150112 21:40:14 server id 1 end_log_pos 367 CRC32 0x19ab4f0f Query thread_id=108 exec_time=0 error_code=0
SET TIMESTAMP=1421079014/*!*/;
BEGIN
/*!*/;
# at 367
#150112 21:40:14 server id 1 end_log_pos 415 CRC32 0x6b1f2240 Table_map: `test`.`t` mapped to number 251
# at 415
#150112 21:40:14 server id 1 end_log_pos 461 CRC32 0x7725d174 Write_rows: table id 251 flags: STMT_END_F
### INSERT INTO `test`.`t`
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’apple’ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
# at 461
#150112 21:40:14 server id 1 end_log_pos 509 CRC32 0x7e44d741 Table_map: `test`.`t` mapped to number 251
# at 509
#150112 21:40:14 server id 1 end_log_pos 569 CRC32 0x0cd1363a Update_rows: table id 251 flags: STMT_END_F
### UPDATE `test`.`t`
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’apple’ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’pear’ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=’2009:01:01′ /* DATE meta=0 nullable=1 is_null=0 */
# at 569
#150112 21:40:14 server id 1 end_log_pos 617 CRC32 0xf134ad89 Table_map: `test`.`t` mapped to number 251
# at 617
#150112 21:40:14 server id 1 end_log_pos 665 CRC32 0x87047106 Delete_rows: table id 251 flags: STMT_END_F
### DELETE FROM `test`.`t`
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’pear’ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=’2009:01:01′ /* DATE meta=0 nullable=1 is_null=0 */
# at 665
#150112 21:40:15 server id 1 end_log_pos 696 CRC32 0x85ffc9ff Xid = 465
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;Row with “Table_map: test.t” defines the table name used by query.Rows with “Write_rows/Update_rows/Delete_rows” defines the event type.Lines that start with “###” defines the actual row that got changed.Columns are represented as @1, @2 and so on.Now have a look at our simple awk script that will use the mysqlbinlog output and print a beautiful summary for INSERT/UPDATE/DELETE events from row-based binary logs. Just replace the “mysqld-bin.000023″ with your binary log file. The string “#15″ in third line is for year 2015. If you are decoding a binary log file from 2014, just change it to “#14″. It is also recommended to use “–start-datetime” and ” –stop-datetime” options to decode binary logs of a specific time range instead of decoding a large binary log file.Script :mysqlbinlog –base64-output=decode-rows -vv –start-datetime=”2015-01-12 21:40:00″ –stop-datetime=”2015-01-12 21:45:00″ mysqld-bin.000023 | awk \
‘BEGIN {s_type=””; s_count=0;count=0;insert_count=0;update_count=0;delete_count=0;flag=0;} \
{if(match($0, /#15.*Table_map:.*mapped to number/)) {printf “Timestamp : ” $1 ” ” $2 ” Table : ” $(NF-4); flag=1} \
else if (match($0, /(### INSERT INTO .*..*)/)) {count=count+1;insert_count=insert_count+1;s_type=”INSERT”; s_count=s_count+1;} \
else if (match($0, /(### UPDATE .*..*)/)) {count=count+1;update_count=update_count+1;s_type=”UPDATE”; s_count=s_count+1;} \
else if (match($0, /(### DELETE FROM .*..*)/)) {count=count+1;delete_count=delete_count+1;s_type=”DELETE”; s_count=s_count+1;} \
else if (match($0, /^(# at) /) && flag==1 && s_count>0) {print ” Query Type : “s_type ” ” s_count ” row(s) affected” ;s_type=””; s_count=0; } \
else if (match($0, /^(COMMIT)/)) {print “[Transaction total : ” count ” Insert(s) : ” insert_count ” Update(s) : ” update_count ” Delete(s) : ” \
delete_count “] \n+———————-+———————-+———————-+———————-+”; \
count=0;insert_count=0;update_count=0; delete_count=0;s_type=””; s_count=0; flag=0} } ‘Output :Timestamp : #150112 21:40:14 Table : `test`.`t` Query Type : INSERT 1 row(s) affected
Timestamp : #150112 21:40:14 Table : `test`.`t` Query Type : UPDATE 1 row(s) affected
Timestamp : #150112 21:40:14 Table : `test`.`t` Query Type : DELETE 1 row(s) affected
[Transaction total : 3 Insert(s) : 1 Update(s) : 1 Delete(s) : 1]
+———————-+———————-+———————-+———————-+This awk script will return following columns as output for every transaction in binary logs.Timestamp : timestamp of event as logged in binary log. Table : database.tablename Query Type : Type of query executed on table and number of rows affected by query.[Transaction total : 3 Insert(s) : 1 Update(s) : 1 Delete(s) : 1] Above line print the summary of transaction, it displays the total number of rows affected by transaction, total number of rows affected by each type of query in transaction.Let’s execute some more queries in sakila database and then we will summarize them using our script. We assume that we executed these queries between “2015-01-16 13:30:00″ and “2015-01-16 14:00:00″use sakila;
mysql> update city set city=”Acua++” where city_id=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> delete from country where country_id=4;
Query OK, 1 row affected (0.04 sec)
mysql> insert into country (country_id,country,last_update) values (‘4′,’Angola’,now());
Query OK, 1 row affected (0.03 sec)
mysql> create table payment_tmp select * from payment;
Query OK, 16049 rows affected (0.80 sec)
Records: 16049 Duplicates: 0 Warnings: 0
mysql> delete from payment_tmp where payment_id between 10000 and 15000;
Query OK, 5001 rows affected (0.08 sec)
mysql> update payment_tmp set amount=9.99 where payment_id between 1 and 7000;
Query OK, 6890 rows affected (0.08 sec)
Rows matched: 7000 Changed: 6890 Warnings: 0
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> delete from country where country_id=5;
Query OK, 1 row affected (0.00 sec)
mysql> delete from city where country_id=5;
Query OK, 1 row affected (0.00 sec)
mysql> delete from address where city_id=300;
Query OK, 2 rows affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.01 sec)We will save our script in a file named “summarize_binlogs.sh” and summarize the queries we just executed.# vim summarize_binlogs.sh
#!/bin/bash
BINLOG_FILE=”mysqld-bin.000035″
START_TIME=”2015-01-16 13:30:00″
STOP_TIME=”2015-01-16 14:00:00″
mysqlbinlog –base64-output=decode-rows -vv –start-datetime=”${START_TIME}” –stop-datetime=”${STOP_TIME}” ${BINLOG_FILE} | awk \
‘BEGIN {s_type=””; s_count=0;count=0;insert_count=0;update_count=0;delete_count=0;flag=0;} \
{if(match($0, /#15.*Table_map:.*mapped to number/)) {printf “Timestamp : ” $1 ” ” $2 ” Table : ” $(NF-4); flag=1} \
else if (match($0, /(### INSERT INTO .*..*)/)) {count=count+1;insert_count=insert_count+1;s_type=”INSERT”; s_count=s_count+1;} \
else if (match($0, /(### UPDATE .*..*)/)) {count=count+1;update_count=update_count+1;s_type=”UPDATE”; s_count=s_count+1;} \
else if (match($0, /(### DELETE FROM .*..*)/)) {count=count+1;delete_count=delete_count+1;s_type=”DELETE”; s_count=s_count+1;} \
else if (match($0, /^(# at) /) && flag==1 && s_count>0) {print ” Query Type : “s_type ” ” s_count ” row(s) affected” ;s_type=””; s_count=0; } \
else if (match($0, /^(COMMIT)/)) {print “[Transaction total : ” count ” Insert(s) : ” insert_count ” Update(s) : ” update_count ” Delete(s) : ” \
delete_count “] \n+———————-+———————-+———————-+———————-+”; \
count=0;insert_count=0;update_count=0; delete_count=0;s_type=””; s_count=0; flag=0} } ‘
:wq
# chmod u+x summarize_binlogs.shNow we run our script to get the summary of information logged in binary log.# ./summarize_binlogs.sh
Timestamp : #150116 13:41:09 Table : `sakila`.`city` Query Type : UPDATE 1 row(s) affected
[Transaction total : 1 Insert(s) : 0 Update(s) : 1 Delete(s) : 0]
+———————-+———————-+———————-+———————-+
Timestamp : #150116 13:41:59 Table : `sakila`.`country` Query Type : DELETE 1 row(s) affected
[Transaction total : 1 Insert(s) : 0 Update(s) : 0 Delete(s) : 1]
+———————-+———————-+———————-+———————-+
Timestamp : #150116 13:42:07 Table : `sakila`.`country` Query Type : INSERT 1 row(s) affected
[Transaction total : 1 Insert(s) : 1 Update(s) : 0 Delete(s) : 0]
+———————-+———————-+———————-+———————-+
Timestamp : #150116 13:42:13 Table : `sakila`.`payment_tmp` Query Type : INSERT 16049 row(s) affected
[Transaction total : 16049 Insert(s) : 16049 Update(s) : 0 Delete(s) : 0]
+———————-+———————-+———————-+———————-+
Timestamp : #150116 13:42:20 Table : `sakila`.`payment_tmp` Query Type : DELETE 5001 row(s) affected
[Transaction total : 5001 Insert(s) : 0 Update(s) : 0 Delete(s) : 5001]
+———————-+———————-+———————-+———————-+
Timestamp : #150116 13:42:28 Table : `sakila`.`payment_tmp` Query Type : UPDATE 6890 row(s) affected
[Transaction total : 6890 Insert(s) : 0 Update(s) : 6890 Delete(s) : 0]
+———————-+———————-+———————-+———————-+
Timestamp : #150116 13:42:42 Table : `sakila`.`country` Query Type : DELETE 1 row(s) affected
Timestamp : #150116 13:42:48 Table : `sakila`.`city` Query Type : DELETE 1 row(s) affected
Timestamp : #150116 13:42:53 Table : `sakila`.`address` Query Type : DELETE 2 row(s) affected
[Transaction total : 4 Insert(s) : 0 Update(s) : 0 Delete(s) : 4]
+———————-+———————-+———————-+———————-+See how nicely our script has summarized the information logged in binary log. For the last transaction, it shows 3 rows that corresponds to each statement executed within transaction and then the final summary of transaction i.e. transaction affected 4 rows in total and all of them were deleted.This was how we can summarize MySQL row-based binary logs in a more readable format using a simple awk script. This will save you time whenever you need to decode the binary logs for troubleshooting. Now I’ll show you how this summarized information can help answer some basic but important questions.Q1 : Which tables received highest number of insert/update/delete statements?./summarize_binlogs.sh | grep Table |cut -d’:’ -f5| cut -d’ ‘ -f2 | sort | uniq -c | sort -nr
3 `sakila`.`payment_tmp`
3 `sakila`.`country`
2 `sakila`.`city`
1 `sakila`.`address`Q2 : Which table received the highest number of DELETE queries?./summarize_binlogs.sh | grep -E ‘DELETE’ |cut -d’:’ -f5| cut -d’ ‘ -f2 | sort | uniq -c | sort -nr
2 `sakila`.`country`
1 `sakila`.`payment_tmp`
1 `sakila`.`city`
1 `sakila`.`address`Q3: How many insert/update/delete queries executed against sakila.country table?./summarize_binlogs.sh | grep -i ‘`sakila`.`country`’ | awk ‘{print $7 ” ” $11}’ | sort -k1,2 | uniq -c
2 `sakila`.`country` DELETE
1 `sakila`.`country` INSERTQ4: Give me the top 3 statements which affected maximum number of rows../summarize_binlogs.sh | grep Table | sort -nr -k 12 | head -n 3
Timestamp : #150116 13:42:13 Table : `sakila`.`payment_tmp` Query Type : INSERT 16049 row(s) affected
Timestamp : #150116 13:42:28 Table : `sakila`.`payment_tmp` Query Type : UPDATE 6890 row(s) affected
Timestamp : #150116 13:42:20 Table : `sakila`.`payment_tmp` Query Type : DELETE 5001 row(s) affectedSee how easy it is to identify the large transactions.Q5 : Find DELETE queries that affected more than 1000 rows../summarize_binlogs.sh | grep -E ‘DELETE’ | awk ‘{if($12>1000) print $0}’
Timestamp : #150116 13:42:20 Table : `sakila`.`payment_tmp` Query Type : DELETE 5001 row(s) affectedIf we want to get all queries that affected more than 1000 rows../summarize_binlogs.sh | grep -E ‘Table’ | awk ‘{if($12>1000) print $0}’
Timestamp : #150116 13:42:13 Table : `sakila`.`payment_tmp` Query Type : INSERT 16049 row(s) affected
Timestamp : #150116 13:42:20 Table : `sakila`.`payment_tmp` Query Type : DELETE 5001 row(s) affected
Timestamp : #150116 13:42:28 Table : `sakila`.`payment_tmp` Query Type : UPDATE 6890 row(s) affectedConclusionThe information logged in binary logs is really helpful to understand our write workload. We used mysqlbinlog + awk to present the binary log contents in more readable format. Further we used the summarized information to answer some of the important questions.The post Identifying useful info from MySQL row-based binary logs appeared first on MySQL Performance Blog.

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569