{"id":7237,"date":"2015-08-04T11:38:13","date_gmt":"2015-08-04T09:38:13","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=7237"},"modified":"2015-08-04T11:38:13","modified_gmt":"2015-08-04T09:38:13","slug":"on-show-binlogrelaylog-events","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/on-show-binlogrelaylog-events","title":{"rendered":"On SHOW BINLOG\/RELAYLOG EVENTS"},"content":{"rendered":"

Some notes after working with SHOW BINLOG EVENTS<\/a> and SHOW RELAYLOG EVENTS<\/a> statements; there are a few gotchas and some interesting facts. My reflections also follow.<\/p>\n

I’m calling these commands from orchestrator<\/a> when working with Pseudo-GTID<\/a> (which I do alot<\/em>). I prefer to work with agent-free design, where a single, remote service can do\u00a0everything: examine replication status, scan binary logs for information, and recover broken topologies via gluing together servers that were not previously directly associated.<\/p>\n

Alas, documentation is short on these commands, and some stuff I learned the hard way.<\/p>\n

Basically, SHOW BINLOG\/RELAYLOG EVENTS<\/strong> commands are a\u00a0poor man’s replacement to mysqlbinlog<\/strong>, only you can issue them on MySQL protocol, and you do not have to have the binary\/relay log files locally on your host.<\/p>\n

Fun\u00a0fact<\/h3>\n

The binary logs are called so because they are compressed. You are familiar with the binlog position you see on SHOW MASTER STATUS<\/strong> or SHOW SLAVE STATUS<\/strong>. You are familiar with the binlog position as you see it when you execute “mysqlbinlog mybinlog.001234”<\/strong>. The position of a new entry equals to the file size of the binary log at that time. If:<\/p>\n

\n
$ ls -l master\/data\/mysql-bin.015901\r\n-rw-rw---- 1 user user 401408 Jul 18 02:44 master\/data\/mysql-bin.015901<\/pre>\n<\/blockquote>\n
Then the next entry will be at position 401408<\/strong>, as this is the file size in bytes.<\/p>\n
And so when MySQL writes an entry to the binary log, it (of course) knows the entry’s position in the binary log, but then also immediately knows the position of the next entry.<\/p>\n
We’ll revisit this fact later.<\/p>\n
Output of SHOW BINLOG\/RELAYLOG EVENTS<\/h3>\n
The output of both statement depends on the binlog_format<\/strong>. In Statement Based Replication it may look like:<\/p>\n
\n
$gt; SHOW BINLOG EVENTS IN 'mysql-bin.015903' LIMIT 40,20;\r\n+------------------+------+------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------+\r\n| Log_name         | Pos  | Event_type | Server_id | End_log_pos | Info                                                                                                                |\r\n+------------------+------+------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------+\r\n| mysql-bin.015903 | 3650 | Gtid       |         1 |        3698 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:790000'                                              |\r\n| mysql-bin.015903 | 3698 | Query      |         1 |        3785 | BEGIN                                                                                                               |\r\n| mysql-bin.015903 | 3785 | User var   |         1 |        3832 | @`id`=7                                                                                                             |\r\n| mysql-bin.015903 | 3832 | Query      |         1 |        3969 | use `test`; replace into test.t (id, i, t) values (@id, @id, now())                                                 |\r\n| mysql-bin.015903 | 3969 | Xid        |         1 |        4000 | COMMIT \/* xid=967 *\/                                                                                                |\r\n| mysql-bin.015903 | 4000 | Gtid       |         1 |        4048 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:790001'                                              |\r\n| mysql-bin.015903 | 4048 | Query      |         1 |        4135 | BEGIN                                                                                                               |\r\n| mysql-bin.015903 | 4135 | User var   |         1 |        4182 | @`id`=9                                                                                                             |\r\n| mysql-bin.015903 | 4182 | Query      |         1 |        4319 | use `test`; replace into test.t (id, i, t) values (@id, @id, now())                                                 |\r\n| mysql-bin.015903 | 4319 | Xid        |         1 |        4350 | COMMIT \/* xid=969 *\/                                                                                                |\r\n| mysql-bin.015903 | 4350 | Gtid       |         1 |        4398 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:790002'                                              |\r\n| mysql-bin.015903 | 4398 | Query      |         1 |        4576 | use `meta`; drop view if exists `meta`.`_pseudo_gtid_hint__asc(55B50F9C:00000000000000D4:C96BF9F7)` |\r\n| mysql-bin.015903 | 4576 | Gtid       |         1 |        4624 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:790003'                                              |\r\n| mysql-bin.015903 | 4624 | Query      |         1 |        4711 | BEGIN                                                                                                               |\r\n| mysql-bin.015903 | 4711 | User var   |         1 |        4758 | @`id`=6                                                                                                             |\r\n| mysql-bin.015903 | 4758 | Query      |         1 |        4895 | use `test`; replace into test.t (id, i, t) values (@id, @id, now())                                                 |\r\n| mysql-bin.015903 | 4895 | Xid        |         1 |        4926 | COMMIT \/* xid=971 *\/                                                                                                |\r\n| mysql-bin.015903 | 4926 | Gtid       |         1 |        4974 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:790004'                                              |\r\n| mysql-bin.015903 | 4974 | Query      |         1 |        5077 | BEGIN                                                                                                               |\r\n| mysql-bin.015903 | 5077 | User var   |         1 |        5133 | @`hostname`=_utf8 0x736E6F6163682D616D7339 COLLATE utf8_general_ci                                                  |\r\n+------------------+------+------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------+\r\n<\/pre>\n<\/blockquote>\n
The first thing to note is that there’s\u00a0far less data in this output as compared to\u00a0mysqlbinlog<\/strong>‘s. For example, you can’t see the TIMESTAMP at which the queries were issued. You can’t see additional metadata like RAND() seed. Thus far it is documented.<\/p>\n
You do know the binlog file name, position, end-position (which is the position of the next entry), originating server_id<\/strong>.<\/p>\n
However with\u00a0Row Based Replication things are even less informative:<\/p>\n
\n
$gt; SHOW BINLOG EVENTS IN 'mysql-bin.015902' LIMIT 20,20;\r\n+------------------+------+-------------+-----------+-------------+------------------------------------------------------------------------+\r\n| Log_name         | Pos  | Event_type  | Server_id | End_log_pos | Info                                                                   |\r\n+------------------+------+-------------+-----------+-------------+------------------------------------------------------------------------+\r\n| mysql-bin.015902 | 1365 | Query       |         1 |        1453 | BEGIN                                                                  |\r\n| mysql-bin.015902 | 1453 | Table_map   |         1 |        1535 | table_id: 71 (meta.pseudo_gtid_status)                                 |\r\n| mysql-bin.015902 | 1535 | Update_rows |         1 |        1829 | table_id: 71 flags: STMT_END_F                                         |\r\n| mysql-bin.015902 | 1829 | Xid         |         1 |        1860 | COMMIT \/* xid=26 *\/                                                    |\r\n| mysql-bin.015902 | 1860 | Gtid        |         1 |        1908 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:789767' |\r\n| mysql-bin.015902 | 1908 | Query       |         1 |        1988 | BEGIN                                                                  |\r\n| mysql-bin.015902 | 1988 | Table_map   |         1 |        2035 | table_id: 70 (test.t)                                                  |\r\n| mysql-bin.015902 | 2035 | Update_rows |         1 |        2129 | table_id: 70 flags: STMT_END_F                                         |\r\n| mysql-bin.015902 | 2129 | Xid         |         1 |        2160 | COMMIT \/* xid=29 *\/                                                    |\r\n| mysql-bin.015902 | 2160 | Gtid        |         1 |        2208 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:789768' |\r\n| mysql-bin.015902 | 2208 | Query       |         1 |        2288 | BEGIN                                                                  |\r\n| mysql-bin.015902 | 2288 | Table_map   |         1 |        2335 | table_id: 70 (test.t)                                                  |\r\n| mysql-bin.015902 | 2335 | Update_rows |         1 |        2429 | table_id: 70 flags: STMT_END_F                                         |\r\n| mysql-bin.015902 | 2429 | Xid         |         1 |        2460 | COMMIT \/* xid=32 *\/                                                    |\r\n| mysql-bin.015902 | 2460 | Gtid        |         1 |        2508 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:789769' |\r\n| mysql-bin.015902 | 2508 | Query       |         1 |        2588 | BEGIN                                                                  |\r\n| mysql-bin.015902 | 2588 | Table_map   |         1 |        2635 | table_id: 70 (test.t)                                                  |\r\n| mysql-bin.015902 | 2635 | Update_rows |         1 |        2729 | table_id: 70 flags: STMT_END_F                                         |\r\n| mysql-bin.015902 | 2729 | Xid         |         1 |        2760 | COMMIT \/* xid=34 *\/                                                    |\r\n| mysql-bin.015902 | 2760 | Gtid        |         1 |        2808 | SET @@SESSION.GTID_NEXT= '230ea8ea-81e3-11e4-972a-e25ec4bd140a:789770' |\r\n+------------------+------+-------------+-----------+-------------+------------------------------------------------------------------------+\r\n<\/pre>\n<\/blockquote>\n
What’s this? We don’t get the statement anymore. I mean, sure, this is RBR, but there’s no more info! All we knows is there was an Update_rows<\/strong> on test.t; that also only after we’ve crossed two different entries, one mapping a test.t to 70<\/strong>, the other telling us an UPDATE<\/strong> operation was made on 70<\/strong>.<\/p>\n
This is the reason why Pseudo GTID injection is made via DDL<\/a>.<\/p>\n
With RBR we also get some excessive information. The table_id<\/strong> mentioned above is true for this server; but on a slave the table would have a different id. The SHOW output would look different. Likewise, the commit number as in “COMMIT \/* xid=32 *\/”<\/strong> changes from server to server. There are also other entries which may look different; character encoding changes shape. Really weird stuff.<\/p>\n
The output of SHOW RELAYLOG EVENTS<\/strong> is very similar, except for the following:<\/p>\n
    \n
  1. Obviously we’re parsing and outputting relay logs<\/li>\n
  2. Pos<\/strong> column relates to the position in the relay log where the entry starts (makes sense)<\/li>\n
  3. End_log_pos<\/strong> column relates to the next binlog position of the master’s binary log<\/em> that correlates to this query. Read that again. There is no telling what the end-log-pos is for the relay log entry. We’ll revisit that shortly.<\/li>\n<\/ol>\n
    Locking issues<\/h3>\n
    Unfortunately, issuing a SHOW BINLOG EVENTS<\/strong>\u00a0completely locks down the binary logs<\/a> on the server.<\/p>\n
    Yes. This means you cannot write to the binary logs while issuing the SHOW<\/strong> statement. And that means you cannot write, everything piles up and your server is under complete lock down.<\/p>\n
    Before you throw your hands up in the air and move on to read something that can cheer you up, note that things\u00a0are\u00a0not completely bad. We are able at Booking.com<\/strong> to scan 24<\/strong> hours worth of binary logs (i.e. dozens of hundreds of binary logs) on business-critical\u00a0MySQL masters without\u00a0making an impact. How?<\/p>\n
    SHOW…LIMIT offset, row_count vs SHOW…FROM pos LIMIT row_count<\/h3>\n
    Of course the\u00a0solution is to do many small steps instead of few giant steps. Reading all of a binary log’s entries is suicidal to your application & database. The SHOW BINLOG\/RELAYLOG EVENTS<\/strong> statements support a LIMIT<\/strong> clause.<\/p>\n
    As per previous example, you may:<\/p>\n
    \n
    SHOW BINLOG EVENTS IN 'mysql-bin.015903' LIMIT 40,20;<\/pre>\n<\/blockquote>\n
    This skips 40<\/strong> entries (offset<\/strong>), then reads 20<\/strong> (row_count<\/strong>).<\/p>\n
    However much like non-indexed table scan, to skip the first 40<\/strong> entries you must nonetheless iterate them. Since we don’t know exactly where in the binlog the 41st<\/strong> entry begins, we need to unpack the binary log from start and find it out the full-scan way.<\/p>\n
    Don’t iterate a binary log’s entries via LIMIT 0,1000<\/strong>; LIMIT 1000,1000<\/strong>; LIMIT 2000,1000<\/strong>; … This is O(n\u00b2)<\/p>\n
    In contrast, you may:<\/p>\n
    \n
    SHOW BINLOG EVENTS IN 'mysql-bin.015903' FROM<\/strong> 3650 LIMIT 20;<\/pre>\n<\/blockquote>\n
    Remember that an entry’s position is the binlog file size at the time before the entry was written? To execute the above MySQL merely seeks<\/strong><\/em> the binlog file 3650 bytes ahead. No scan required.<\/p>\n
    You must provide with a valid position value. If I just guess my way:<\/p>\n
    \n
    > SHOW BINLOG EVENTS IN 'mysql-bin.015903' FROM 3651 LIMIT 20;\r\nERROR 1220 (HY000): Error when executing command SHOW BINLOG EVENTS: Wrong offset or I\/O error<\/pre>\n<\/blockquote>\n
    And so you must have prior knowledge about positions. This is fine if you’re scanning a binary log: you simply read the End_log_pos<\/strong> of the last entry you’ve just read and memorize it. Thus, to scan a binary log, you can:<\/p>\n
    \n
    >\u00a0SHOW BINLOG EVENTS IN 'mysql-bin.015903' LIMIT 20;\r\n\r\n>\u00a0SHOW BINLOG EVENTS IN 'mysql-bin.015903' FROM 1499 LIMIT 20;\r\n\r\n>\u00a0SHOW BINLOG EVENTS IN 'mysql-bin.015903' FROM\u00a03651 LIMIT 20;<\/pre>\n<\/blockquote>\n
    But it’s more difficult to do this for relay logs: remember that the End_log_pos<\/strong>\u00a0in SHOW RELAYLOG EVENTS<\/strong> relates to the next position in the master’s binary log<\/em>. So you need to resort to an off-by-one or something. However the good news is that reading relay logs does not<\/em> block writes on your server.<\/p>\n
    Locking thoughts<\/h3>\n
    As per my comments in the bug report, I don’t see why SHOW BINLOG EVENTS<\/strong> should always lock writes:<\/p>\n
      \n
    • If we’re scanning an old binary log (not the one being written to) then obviously we should not be blocking\u00a0writes.<\/li>\n
    • If we’re scanning the current binlog, but are known to end with a statement that is already written (i.e. not trying to scan past the current writing position) then we should not be blocking writes.<\/li>\n
    • OK to block writes when trying to read past current position.<\/li>\n
    • OK to block on a FLUSH MASTER LOGS<\/strong>, PURGE MASTER LOGS<\/strong><\/li>\n<\/ul>\n
      Why is the output so limited?<\/h3>\n
      I’m actually unsure why the output of these commands is so limited as compared to the mysqlbinlog<\/strong> output. A replicating slave talks to the master over MySQL protocol; the slave does get<\/em> all the data right. It does get<\/em> event metadata (timestamp, random seed, session variable). It does get<\/em> complete statement\/row data. What I’m saying is that this functionality is already built in; it could be very easily added to the SHOW<\/strong> commands.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Some notes after working with SHOW BINLOG EVENTS and SHOW RELAYLOG EVENTS statements; there are a few gotchas and some interesting facts. My reflections also follow. I’m calling these commands from orchestrator when working with Pseudo-GTID (which I do alot). I prefer to work with agent-free design, where a single, remote service can do\u00a0everything: examine […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[8],"class_list":["post-7237","post","type-post","status-publish","format-standard","hentry","category-mysql","tag-replication"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-1SJ","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7237","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=7237"}],"version-history":[{"count":18,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7237\/revisions"}],"predecessor-version":[{"id":7326,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/7237\/revisions\/7326"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=7237"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=7237"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=7237"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}