解析MYSQL BINLOG 二进制格式(3)--QUERY_EVENT

点击(此处)折叠或打开

1. 00000100          d3 a5 9b 58 02 e5 6b 01 00 bd 00 00 00 |    ..X..k......|
   
2. 00000110 c0 01 00 00 00 00 02 00 00 00 01 00 00 00 04 00 |................|
   
3. 00000120 00 1a 00 00 00 00 00 00 01 00 00 20 40 00 00 00 |........... @...|
   
4. 00000130 00 06 03 73 74 64 04 21 00 21 00 21 00 74 65 73 |...std.!.!.!.tes|
   
5. 00000140 74 00 43 52 45 41 54 45 20 54 41 42 4c 45 20 60 |t.CREATE TABLE `|
   
6. 00000150 74 65 73 74 63 74 61 73 31 60 20 28 0a 20 20 60 |testctas1` (. `|
   
7. 00000160 69 64 31 60 20 69 6e 74 28 31 31 29 20 44 45 46 |id1` int(11) DEF|
   
8. 00000170 41 55 4c 54 20 4e 55 4c 4c 2c 0a 20 20 60 69 64 |AULT NULL,. `id|
   
9. 00000180 32 60 20 69 6e 74 28 31 31 29 20 44 45 46 41 55 |2` int(11) DEFAU|
   
10. 00000190 4c 54 20 4e 55 4c 4c 2c 0a 20 20 60 6e 61 6d 65 |LT NULL,. `name|
    
11. 000001a0 60 20 76 61 72 63 68 61 72 28 32 30 29 20 44 45 |` varchar(20) DE|
    
12. 000001b0 46 41 55 4c 54 20 4e 55 4c 4c 0a 29 66 a6 84 c9 |FAULT NULL.)f...|

点击(此处)折叠或打开

1. 00000140 74 00 43 52 45 41 54 45 20 54 41 42 4c 45 20 60 |t.CREATE TABLE `|
   
2. 00000150 74 65 73 74 63 74 61 73 31 60 20 28 0a 20 20 60 |testctas1` (. `|
   
3. 00000160 69 64 31 60 20 69 6e 74 28 31 31 29 20 44 45 46 |id1` int(11) DEF|
   
4. 00000170 41 55 4c 54 20 4e 55 4c 4c 2c 0a 20 20 60 69 64 |AULT NULL,. `id|
   
5. 00000180 32 60 20 69 6e 74 28 31 31 29 20 44 45 46 41 55 |2` int(11) DEFAU|
   
6. 00000190 4c 54 20 4e 55 4c 4c 2c 0a 20 20 60 6e 61 6d 65 |LT NULL,. `name|
   
7. 000001a0 60 20 76 61 72 63 68 61 72 28 32 30 29 20 44 45 |` varchar(20) DE|
   
8. 000001b0 46 41 55 4c 54 20 4e 55 4c 4c 0a 29 66 a6 84 c9 |FAULT NULL.)f...|

点击(此处)折叠或打开

1. @anchor Table_query_log_event_status_vars
   
2.   <table>
   
3.   <caption>Status variables for Query_log_event</caption>
   
4. 
   
5.   <tr>
   
6.     <th>Status variable</th>
   
7.     <th>1 byte identifier</th>
   
8.     <th>Format</th>
   
9.     <th>Description</th>
   
10.   </tr>
    
11. 
    
12.   <tr>
    
13.     <td>flags2</td>
    
14.     <td>Q_FLAGS2_CODE == 0</td>
    
15.     <td>4 byte bitfield</td>
    
16.     <td>The flags in @c thd->options, binary AND-ed with @c
    
17.     OPTIONS_WRITTEN_TO_BIN_LOG. The @c thd->options bitfield contains
    
18.     options for "SELECT". @c OPTIONS_WRITTEN identifies those options
    
19.     that need to be written to the binlog (not all do). Specifically,
    
20.     @c OPTIONS_WRITTEN_TO_BIN_LOG equals (@c OPTION_AUTO_IS_NULL | @c
    
21.     OPTION_NO_FOREIGN_KEY_CHECKS | @c OPTION_RELAXED_UNIQUE_CHECKS |
    
22.     @c OPTION_NOT_AUTOCOMMIT), or 0x0c084000 in hex.
    
23. 
    
24.     These flags correspond to the SQL variables SQL_AUTO_IS_NULL,
    
25.     FOREIGN_KEY_CHECKS, UNIQUE_CHECKS, and AUTOCOMMIT, documented in
    
26.     the "SET Syntax" section of the MySQL Manual.
    
27. 
    
28.     This field is always written to the binlog in version >= 5.0, and
    
29.     never written in version < 5.0.
    
30.     </td>
    
31.   </tr>
    
32. 
    
33.   <tr>
    
34.     <td>sql_mode</td>
    
35.     <td>Q_SQL_MODE_CODE == 1</td>
    
36.     <td>8 byte bitfield</td>
    
37.     <td>The @c sql_mode variable. See the section "SQL Modes" in the
    
38.     MySQL manual, and see sql_priv.h for a list of the possible
    
39.     flags. Currently (2007-10-04), the following flags are available:
    
40.     <pre>
    
41.     MODE_REAL_AS_FLOAT==0x1
    
42.     MODE_PIPES_AS_CONCAT==0x2
    
43.     MODE_ANSI_QUOTES==0x4
    
44.     MODE_IGNORE_SPACE==0x8
    
45.     MODE_NOT_USED==0x10
    
46.     MODE_ONLY_FULL_GROUP_BY==0x20
    
47.     MODE_NO_UNSIGNED_SUBTRACTION==0x40
    
48.     MODE_NO_DIR_IN_CREATE==0x80
    
49.     MODE_POSTGRESQL==0x100
    
50.     MODE_ORACLE==0x200
    
51.     MODE_MSSQL==0x400
    
52.     MODE_DB2==0x800
    
53.     MODE_MAXDB==0x1000
    
54.     MODE_NO_KEY_OPTIONS==0x2000
    
55.     MODE_NO_TABLE_OPTIONS==0x4000
    
56.     MODE_NO_FIELD_OPTIONS==0x8000
    
57.     MODE_MYSQL323==0x10000
    
58.     MODE_MYSQL323==0x20000
    
59.     MODE_MYSQL40==0x40000
    
60.     MODE_ANSI==0x80000
    
61.     MODE_NO_AUTO_VALUE_ON_ZERO==0x100000
    
62.     MODE_NO_BACKSLASH_ESCAPES==0x200000
    
63.     MODE_STRICT_TRANS_TABLES==0x400000
    
64.     MODE_STRICT_ALL_TABLES==0x800000
    
65.     MODE_NO_ZERO_IN_DATE==0x1000000
    
66.     MODE_NO_ZERO_DATE==0x2000000
    
67.     MODE_INVALID_DATES==0x4000000
    
68.     MODE_ERROR_FOR_DIVISION_BY_ZERO==0x8000000
    
69.     MODE_TRADITIONAL==0x10000000
    
70.     MODE_NO_AUTO_CREATE_USER==0x20000000
    
71.     MODE_HIGH_NOT_PRECEDENCE==0x40000000
    
72.     MODE_PAD_CHAR_TO_FULL_LENGTH==0x80000000
    
73.     </pre>
    
74.     All these flags are replicated from the server. However, all
    
75.     flags except @c MODE_NO_DIR_IN_CREATE are honored by the slave;
    
76.     the slave always preserves its old value of @c
    
77.     MODE_NO_DIR_IN_CREATE. For a rationale, see comment in
    
78.     @c Query_log_event::do_apply_event in @c log_event.cc.
    
79. 
    
80.     This field is always written to the binlog.
    
81.     </td>
    
82.   </tr>
    
83. 
    
84.   <tr>
    
85.     <td>catalog</td>
    
86.     <td>Q_CATALOG_NZ_CODE == 6</td>
    
87.     <td>Variable-length string: the length in bytes (1 byte) followed
    
88.     by the characters (at most 255 bytes)
    
89.     </td>
    
90.     <td>Stores the client's current catalog. Every database belongs
    
91.     to a catalog, the same way that every table belongs to a
    
92.     database. Currently, there is only one catalog, "std".
    
93. 
    
94.     This field is written if the length of the catalog is > 0;
    
95.     otherwise it is not written.
    
96.     
    
97.   
    
98. 
    
99.   
    
100.     auto_increment
     
101.     Q_AUTO_INCREMENT == 3
     
102.     two 2 byte unsigned integers, totally 2+2=4 bytes
     
103. 
     
104.     The two variables auto_increment_increment and
     
105.     auto_increment_offset, in that order. For more information, see
     
106.     "System variables" in the MySQL manual.
     
107. 
     
108.     This field is written if auto_increment > 1. Otherwise, it is not
     
109.     written.
     
110.     
     
111.   
     
112. 
     
113.   
     
114.     charset
     
115.     Q_CHARSET_CODE == 4
     
116.     three 2 byte unsigned integers, totally 2+2+2=6 bytes
     
117.     The three variables character_set_client,
     
118.     collation_connection, and collation_server, in that order.
     
119.     character_set_client is a code identifying the character set and
     
120.     collation used by the client to encode the query.
     
121.     collation_connection identifies the character set and collation
     
122.     that the master converts the query to when it receives it; this is
     
123.     useful when comparing literal strings. collation_server is the
     
124.     default character set and collation used when a new database is
     
125.     created.
     
126. 
     
127.     See also "Connection Character Sets and Collations" in the MySQL
     
128.     5.1 manual.
     
129. 
     
130.     All three variables are codes identifying a (character set,
     
131.     collation) pair. To see which codes map to which pairs, run the
     
132.     query "SELECT id, character_set_name, collation_name FROM
     
133.     COLLATIONS".
     
134. 
     
135.     Cf. Q_CHARSET_DATABASE_CODE below.
     
136. 
     
137.     This field is always written.
     
138.     
     
139.   
     
140. 
     
141.   
     
142.     time_zone
     
143.     Q_TIME_ZONE_CODE == 5
     
144.     Variable-length string: the length in bytes (1 byte) followed
     
145.     by the characters (at most 255 bytes).
     
146.     The time_zone of the master.
     
147.     
     
148.     See also "System Variables" and "MySQL Server Time Zone Support"
     
149.     in the MySQL manual.
     
150. 
     
151.     This field is written if the length of the time zone string is >
     
152.     0; otherwise, it is not written.
     
153.     
     
154.   
     
155. 
     
156.   
     
157.     lc_time_names_number
     
158.     Q_LC_TIME_NAMES_CODE == 7
     
159.     2 byte integer
     
160.     A code identifying a table of month and day names. The
     
161.     mapping from codes to languages is defined in @c sql_locale.cc.
     
162. 
     
163.     This field is written if it is not 0, i.e., if the locale is not
     
164.     en_US.
     
165.     
     
166.   
     
167. 
     
168.   
     
169.     charset_database_number
     
170.     Q_CHARSET_DATABASE_CODE == 8
     
171.     2 byte integer
     
172. 
     
173.     The value of the collation_database system variable (in the
     
174.     source code stored in @c thd->variables.collation_database), which
     
175.     holds the code for a (character set, collation) pair as described
     
176.     above (see Q_CHARSET_CODE).
     
177. 
     
178.     collation_database was used in old versions (???WHEN). Its value
     
179.     was loaded when issuing a "use db" query and could be changed by
     
180.     issuing a "SET collation_database=xxx" query. It used to affect
     
181.     the "LOAD DATA INFILE" and "CREATE TABLE" commands.
     
182. 
     
183.     In newer versions, "CREATE TABLE" has been changed to take the
     
184.     character set from the database of the created table, rather than
     
185.     the character set of the current database. This makes a
     
186.     difference when creating a table in another database than the
     
187.     current one. "LOAD DATA INFILE" has not yet changed to do this,
     
188.     but there are plans to eventually do it, and to make
     
189.     collation_database read-only.
     
190. 
     
191.     This field is written if it is not 0.
     
192.     
     
193.   
     
194.   
     
195.     table_map_for_update
     
196.     Q_TABLE_MAP_FOR_UPDATE_CODE == 9
     
197.     8 byte integer
     
198. 
     
199.     The value of the table map that is to be updated by the
     
200.     multi-table update query statement. Every bit of this variable
     
201.     represents a table, and is set to 1 if the corresponding table is
     
202.     to be updated by this statement.
     
203. 
     
204.     The value of this variable is set when executing a multi-table update
     
205.     statement and used by slave to apply filter rules without opening
     
206.     all the tables on slave. This is required because some tables may
     
207.     not exist on slave because of the filter rules.
     
208.     
     
209.   
     
210.   
     
211. 
     
212.   @subsection Query_log_event_notes_on_previous_versions Notes on Previous Versions
     
213. 
     
214.   * Status vars were introduced in version 5.0. To read earlier
     
215.   versions correctly, check the length of the Post-Header.
     
216. 
     
217.   * The status variable Q_CATALOG_CODE == 2 existed in MySQL 5.0.x,
     
218.   where 0<=x<=3. It was identical to Q_CATALOG_CODE, except that the
     
219.   string had a trailing '/0'. The '/0' was removed in 5.0.4 since it
     
220.   was redundant (the string length is stored before the string). The
     
221.   Q_CATALOG_CODE will never be written by a new master, but can still
     
222.   be understood by a new slave.
     
223. 
     
224.   * See Q_CHARSET_DATABASE_CODE in the table above.
     
225. 
     
226.   * When adding new status vars, please don't forget to update the
     
227.   MAX_SIZE_LOG_EVENT_STATUS, and update function code_name
     
228. 
     
229. */
     
230. class Query_log_event: public Log_event
     
231. {
     
232.   LEX_STRING user;
     
233.   LEX_STRING host;
     
234. protected:
     
235.   Log_event::Byte* data_buf;
     
236. public:
     
237.   const char* query;
     
238.   const char* catalog;
     
239.   const char* db;
     
240.   /*
     
241.     If we already know the length of the query string
     
242.     we pass it with q_len, so we would not have to call strlen()
     
243.     otherwise, set it to 0, in which case, we compute it with strlen()
     
244.   */
     
245.   uint32 q_len;
     
246.   uint32 db_len;
     
247.   uint16 error_code;
     
248.   ulong thread_id;
     
249.   /*
     
250.     For events created by Query_log_event::do_apply_event (and
     
251.     Load_log_event::do_apply_event()) we need the *original* thread
     
252.     id, to be able to log the event with the original (=master's)
     
253.     thread id (fix for BUG#1686).
     
254.   */
     
255.   ulong slave_proxy_id;
     
256. 
     
257.   /*
     
258.     Binlog format 3 and 4 start to differ (as far as class members are
     
259.     concerned) from here.
     
260.   */
     
261. 
     
262.   uint catalog_len;            // <= 255 char; 0 means uninited
     
263. 
     
264.   /*
     
265.     We want to be able to store a variable number of N-bit status vars:
     
266.     (generally N=32; but N=64 for SQL_MODE) a user may want to log the number
     
267.     of affected rows (for debugging) while another does not want to lose 4
     
268.     bytes in this.
     
269.     The storage on disk is the following:
     
270.     status_vars_len is part of the post-header,
     
271.     status_vars are in the variable-length part, after the post-header, before
     
272.     the db & query.
     
273.     status_vars on disk is a sequence of pairs (code, value) where 'code' means
     
274.     'sql_mode', 'affected' etc. Sometimes 'value' must be a short string, so
     
275.     its first byte is its length. For now the order of status vars is:
     
276.     flags2 - sql_mode - catalog - autoinc - charset
     
277.     We should add the same thing to Load_log_event, but in fact
     
278.     LOAD DATA INFILE is going to be logged with a new type of event (logging of
     
279.     the plain text query), so Load_log_event would be frozen, so no need. The
     
280.     new way of logging LOAD DATA INFILE would use a derived class of
     
281.     Query_log_event, so automatically benefit from the work already done for
     
282.     status variables in Query_log_event.
     
283.  */
     
284.   uint16 status_vars_len;
     
285. 
     
286.   /*
     
287.     'flags2' is a second set of flags (on top of those in Log_event), for
     
288.     session variables. These are thd->options which is & against a mask
     
289.     (OPTIONS_WRITTEN_TO_BIN_LOG).
     
290.     flags2_inited helps make a difference between flags2==0 (3.23 or 4.x
     
291.     master, we don't know flags2, so use the slave server