1MK-TABLE-CHECKSUM(1)  User Contributed Perl Documentation MK-TABLE-CHECKSUM(1)
2
3
4

NAME

6       mk-table-checksum - Perform an online replication consistency check, or
7       checksum MySQL tables efficiently on one or many servers.
8

SYNOPSIS

10       STOP! Are you checksumming a slave(s) against its master?  Then be sure
11       to learn what "--replicate" does.  It is probably the option you want
12       to use.
13
14          mk-table-checksum --replicate=mydb.checksum master-host
15          ... time passses, replication catches up ...
16          mk-table-checksum --replicate=mydb.checksum --replicate-check 2 master-host
17
18       Or,
19
20          mk-table-checksum h=host1,u=user,p=password h=host2 ...
21
22       Or,
23
24          mk-table-checksum host1 host2 ... hostN | mk-checksum-filter
25
26       See "SPECIFYING HOSTS" for more on the syntax of the host arguments.
27

RISKS

29       The following section is included to inform users about the potential
30       risks, whether known or unknown, of using this tool.  The two main
31       categories of risks are those created by the nature of the tool (e.g.
32       read-only tools vs. read-write tools) and those created by bugs.
33
34       mk-table-checksum executes queries that cause the MySQL server to
35       checksum its data.  This can cause significant server load.  It is
36       read-only unless you use the "--replicate" option, in which case it
37       inserts a small amount of data into the specified table.
38
39       At the time of this release, we know of no bugs that could cause
40       serious harm to users.  There are miscellaneous bugs that might be
41       annoying.
42
43       The authoritative source for updated information is always the online
44       issue tracking system.  Issues that affect this tool will be marked as
45       such.  You can see a list of such issues at the following URL:
46       http://www.maatkit.org/bugs/mk-table-checksum
47       <http://www.maatkit.org/bugs/mk-table-checksum>.
48
49       See also "BUGS" for more information on filing bugs and getting help.
50

DESCRIPTION

52       mk-table-checksum generates table checksums for MySQL tables, typically
53       useful for verifying your slaves are in sync with the master.  The
54       checksums are generated by a query on the server, and there is very
55       little network traffic as a result.
56
57       Checksums typically take about twice as long as COUNT(*) on very large
58       InnoDB tables in my tests.  For smaller tables, COUNT(*) is a good bit
59       faster than the checksums.  See "--algorithm" for more details on
60       performance.
61
62       If you specify more than one server, mk-table-checksum assumes the
63       first server is the master and others are slaves.  Checksums are
64       parallelized for speed, forking off a child process for each table.
65       Duplicate server names are ignored, but if you want to checksum a
66       server against itself you can use two different forms of the hostname
67       (for example, "localhost 127.0.0.1", or "h=localhost,P=3306
68       h=localhost,P=3307").
69
70       If you want to compare the tables in one database to those in another
71       database on the same server, just checksum both databases:
72
73          mk-table-checksum --databases db1,db2
74
75       You can then use mk-checksum-filter to compare the results in both
76       databases easily.
77
78       mk-table-checksum examines table structure only on the first host
79       specified, so if anything differs on the others, it won't notice.  It
80       ignores views.
81
82       The checksums work on MySQL version 3.23.58 through 6.0-alpha.  They
83       will not necessarily produce the same values on all versions.
84       Differences in formatting and/or space-padding between 4.1 and 5.0, for
85       example, will cause the checksums to be different.
86

SPECIFYING HOSTS

88       mk-table-checksum connects to a theoretically unlimited number of MySQL
89       servers.  You specify a list of one or more host definitions on the
90       command line, such as "host1 host2".  Each host definition can be just
91       a hostname, or it can be a complex string that specifies connection
92       options as well.  You can specify connection options two ways:
93
94       ·   Format a host definition in a key=value,key=value form.  If an
95           argument on the command line contains the letter '=', mk-table-
96           checksum will parse it into its component parts.  Examine the
97           "--help" output for details on the allowed keys.
98
99           Specifying a list of simple host definitions "host1 host2" is
100           equivalent to the more complicated "h=host1 h=host2" format.
101
102       ·   With the command-line options such as "--user" and "--password".
103           These options, if given, apply globally to all host definitions.
104
105       In addition to specifying connection options this way, mk-table-
106       checksum allows shortcuts.  Any options specified for the first host
107       definition on the command line fill in missing values in subsequent
108       ones.  Any options that are still missing after this are filled in from
109       the command-line options if possible.
110
111       In other words, the places you specify connection options have
112       precedence: highest precedence is the option specified directly in the
113       host definition, next is the option specified in the first host
114       definition, and lowest is the command-line option.
115
116       You can mix simple and complex host definitions and/or command-line
117       arguments.  For example, if all your servers except one of your slaves
118       uses a non-standard port number:
119
120          mk-table-checksum --port 4500 master h=slave1,P=3306 slave2 slave3
121
122       If you are confused about how mk-table-checksum will connect to your
123       servers, give the "--explain-hosts" option and it will tell you.
124

HOW FAST IS IT?

126       Speed and efficiency are important, because the typical use case is
127       checksumming large amounts of data.
128
129       "mk-table-checksum" is designed to do very little work itself, and
130       generates very little network traffic aside from inspecting table
131       structures with "SHOW CREATE TABLE".  The results of checksum queries
132       are typically 40-character or shorter strings.
133
134       The MySQL server does the bulk of the work, in the form of the checksum
135       queries.  The following benchmarks show the checksum query times for
136       various checksum algorithms.  The first two results are simply running
137       "COUNT(col8)" and "CHECKSUM TABLE" on the table.  "CHECKSUM TABLE" is
138       just "CRC32" under the hood, but it's implemented inside the storage
139       engine layer instead of at the MySQL layer.
140
141        ALGORITHM       HASH FUNCTION  EXTRA           TIME
142        ==============  =============  ==============  =====
143        COUNT(col8)                                    2.3
144        CHECKSUM TABLE                                 5.3
145        BIT_XOR         FNV_64                         12.7
146        ACCUM           FNV_64                         42.4
147        BIT_XOR         MD5            --optimize-xor  80.0
148        ACCUM           MD5                            87.4
149        BIT_XOR         SHA1           --optimize-xor  90.1
150        ACCUM           SHA1                           101.3
151        BIT_XOR         MD5                            172.0
152        BIT_XOR         SHA1                           197.3
153
154       The tests are entirely CPU-bound.  The sample data is an InnoDB table
155       with the following structure:
156
157        CREATE TABLE test (
158          col1 int NOT NULL,
159          col2 date NOT NULL,
160          col3 int NOT NULL,
161          col4 int NOT NULL,
162          col5 int,
163          col6 decimal(3,1),
164          col7 smallint unsigned NOT NULL,
165          col8 timestamp NOT NULL,
166          PRIMARY KEY  (col2, col1),
167          KEY (col7),
168          KEY (col1)
169        ) ENGINE=InnoDB
170
171       The table has 4303585 rows, 365969408 bytes of data and 173457408 bytes
172       of indexes.  The server is a Dell PowerEdge 1800 with dual 32-bit Xeon
173       2.8GHz processors and 2GB of RAM.  The tests are fully CPU-bound, and
174       the server is otherwise idle.  The results are generally consistent to
175       within a tenth of a second on repeated runs.
176
177       "CRC32" is the default checksum function to use, and should be enough
178       for most cases.  If you need stronger guarantees that your data is
179       identical, you should use one of the other functions.
180

ALGORITHM SELECTION

182       The "--algorithm" option allows you to specify which algorithm you
183       would like to use, but it does not guarantee that mk-table-checksum
184       will use this algorithm.  mk-table-checksum will ultimately select the
185       best algorithm possible given various factors such as the MySQL version
186       and other command line options.
187
188       The three basic algorithms in descending order of preference are
189       CHECKSUM, BIT_XOR and ACCUM.  CHECKSUM cannot be used if any one of
190       these criteria is true:
191
192         * L<"--where"> is used.
193         * L<"--since"> is used.
194         * L<"--chunk-size"> is used.
195         * L<"--replicate"> is used.
196         * L<"--count"> is used.
197         * MySQL version less than 4.1.1.
198
199       The BIT_XOR algorithm also requires MySQL version 4.1.1 or later.
200
201       After checking these criteria, if the requested "--algorithm" remains
202       then it is used, otherwise the first remaining algorithm with the
203       highest preference is used.
204

CONSISTENT CHECKSUMS

206       If you are using this tool to verify your slaves still have the same
207       data as the master, which is why I wrote it, you should read this
208       section.
209
210       The best way to do this with replication is to use the "--replicate"
211       option.  When the queries are finished running on the master and its
212       slaves, you can go to the slaves and issue SQL queries to see if any
213       tables are different from the master.  Try the following:
214
215         SELECT db, tbl, chunk, this_cnt-master_cnt AS cnt_diff,
216            this_crc <> master_crc OR ISNULL(master_crc) <> ISNULL(this_crc)
217               AS crc_diff
218         FROM checksum
219         WHERE master_cnt <> this_cnt OR master_crc <> this_crc
220            OR ISNULL(master_crc) <> ISNULL(this_crc);
221
222       The "--replicate-check" option can do this query for you.  If you can't
223       use this method, try the following:
224
225       ·   If your servers are not being written to, you can just run the tool
226           with no further ado:
227
228             mk-table-checksum server1 server2 ... serverN
229
230       ·   If the servers are being written to, you need some way to make sure
231           they are consistent at the moment you run the checksums.  For
232           situations other than master-slave replication, you will have to
233           figure this out yourself.  You may be able to use the "--where"
234           option with a date or time column to only checksum data that's not
235           recent.
236
237       ·   If you are checksumming a master and slaves, you can do a fast
238           parallel checksum and assume the slaves are caught up to the
239           master.  In practice, this tends to work well except for tables
240           which are constantly updated.  You can use the "--slave-lag" option
241           to see how far behind each slave was when it checksummed a given
242           table.  This can help you decide whether to investigate further.
243
244       ·   The next most disruptive technique is to lock the table on the
245           master, then take checksums.  This should prevent changes from
246           propagating to the slaves.  You can just lock on the master (with
247           "--lock"), or you can both lock on the master and wait on the
248           slaves till they reach that point in the master's binlog
249           ("--wait").  Which is better depends on your workload; only you
250           know that.
251
252       ·   If you decide to make the checksums on the slaves wait until
253           they're guaranteed to be caught up to the master, the algorithm
254           looks like this:
255
256            For each table,
257              Master: lock table
258              Master: get pos
259              In parallel,
260                Master: checksum
261                Slave(s): wait for pos, then checksum
262              End
263              Master: unlock table
264            End
265
266       What I typically do when I'm not using the "--replicate" option is
267       simply run the tool on all servers with no further options.  This runs
268       fast, parallel, non-blocking checksums simultaneously.  If there are
269       tables that look different, I re-run with "--wait"=600 on the tables in
270       question.  This makes the tool lock on the master as explained above.
271

OUTPUT

273       Output is to STDOUT, one line per server and table, with header lines
274       for each database.  I tried to make the output easy to process with
275       awk.  For this reason columns are always present.  If there's no value,
276       mk-table-checksum prints 'NULL'.
277
278       The default is column-aligned output for human readability, but you can
279       change it to tab-separated if you want.  Use the "--tab" option for
280       this.
281
282       Output is unsorted, though all lines for one table should be output
283       together.  For speed, all checksums are done in parallel (as much as
284       possible) and may complete out of the order in which they were started.
285       You might want to run them through another script or command-line
286       utility to make sure they are in the order you want.  If you pipe the
287       output through mk-checksum-filter, you can sort the output and/or avoid
288       seeing output about tables that have no differences.
289
290       The columns in the output are as follows.  The database, table, and
291       chunk come first so you can sort by them easily (they are the "primary
292       key").
293
294       Output from "--replicate-check" and "--checksum" are different.
295
296       DATABASE
297           The database the table is in.
298
299       TABLE
300           The table name.
301
302       CHUNK
303           The chunk (see "--chunk-size").  Zero if you are not doing chunked
304           checksums.
305
306       HOST
307           The server's hostname.
308
309       ENGINE
310           The table's storage engine.
311
312       COUNT
313           The table's row count, unless you specified to skip it.
314
315       CHECKSUM
316           The table's checksum, unless you specified to skip it or the table
317           has no rows.  some types of checksums will be 0 if there are no
318           rows; others will print NULL.
319
320       TIME
321           The time the actual checksum and/or counting took.
322
323       WAIT
324           How long the checksum blocked before beginning.
325
326       STAT
327           The return value of MASTER_POS_WAIT().
328
329       LAG How far the slave lags the master, as reported by SHOW SLAVE
330           STATUS.
331

EXIT STATUS

333       A successful exit status is 0.  If there is an error checksumming any
334       table, the exit status is 1.
335
336       When running "--replicate-check", if any slave has chunks that differ
337       from the master, the exit status is 1.
338

QUERIES

340       If you are using innotop (see <http://code.google.com/p/innotop>),
341       mytop, or another tool to watch currently running MySQL queries, you
342       may see the checksum queries.  They look similar to this:
343
344         REPLACE /*test.test_tbl:'2'/'5'*/ INTO test.checksum(db, ...
345
346       Since mk-table-checksum's queries run for a long time and tend to be
347       textually very long, and thus won't fit on one screen of these
348       monitoring tools, I've been careful to place a comment at the beginning
349       of the query so you can see what it is and what it's doing.  The
350       comment contains the name of the table that's being checksummed, the
351       chunk it is currently checksumming, and how many chunks will be
352       checksummed.  In the case above, it is checksumming chunk 2 of 5 in
353       table test.test_tbl.
354

OPTIONS

356       "--schema" is restricted to option groups Connection, Filter, Output,
357       Help, Config, Safety.
358
359       --algorithm
360           type: string
361
362           Checksum algorithm (ACCUM|CHECKSUM|BIT_XOR).
363
364           Specifies which checksum algorithm to use.  Valid arguments are
365           CHECKSUM, BIT_XOR and ACCUM.  The latter two do cryptographic hash
366           checksums.  See also "ALGORITHM SELECTION".
367
368           CHECKSUM is built into MySQL, but has some disadvantages.  BIT_XOR
369           and ACCUM are implemented by SQL queries.  They use a cryptographic
370           hash of all columns concatenated together with a separator,
371           followed by a bitmap of each nullable column that is NULL
372           (necessary because CONCAT_WS() skips NULL columns).
373
374           CHECKSUM is the default.  This method uses MySQL's built-in
375           CHECKSUM TABLE command, which is a CRC32 behind the scenes.  It
376           cannot be used before MySQL 4.1.1, and various options disable it
377           as well.  It does not simultaneously count rows; that requires an
378           extra COUNT(*) query.  This is a good option when you are using
379           MyISAM tables with live checksums enabled; in this case both the
380           COUNT(*) and CHECKSUM queries will run very quickly.
381
382           The BIT_XOR algorithm is available for MySQL 4.1.1 and newer.  It
383           uses BIT_XOR(), which is order-independent, to reduce all the rows
384           to a single checksum.
385
386           ACCUM uses a user variable as an accumulator.  It reduces each row
387           to a single checksum, which is concatenated with the accumulator
388           and re-checksummed.  This technique is order-dependent.  If the
389           table has a primary key, it will be used to order the results for
390           consistency; otherwise it's up to chance.
391
392           The pathological worst case is where identical rows will cancel
393           each other out in the BIT_XOR.  In this case you will not be able
394           to distinguish a table full of one value from a table full of
395           another value.  The ACCUM algorithm will distinguish them.
396
397           However, the ACCUM algorithm is order-dependent, so if you have two
398           tables with identical data but the rows are out of order, you'll
399           get different checksums with ACCUM.
400
401           If a given algorithm won't work for some reason, mk-table-checksum
402           falls back to another.  The least common denominator is ACCUM,
403           which works on MySQL 3.23.2 and newer.
404
405       --arg-table
406           type: string
407
408           The database.table with arguments for each table to checksum.
409
410           This table may be named anything you wish.  It must contain at
411           least the following columns:
412
413             CREATE TABLE checksum_args (
414                db         char(64)     NOT NULL,
415                tbl        char(64)     NOT NULL,
416                -- other columns as desired
417                PRIMARY KEY (db, tbl)
418             );
419
420           In addition to the columns shown, it may contain any of the other
421           columns listed here (Note: this list is used by the code,
422           MAGIC_overridable_args):
423
424             algorithm chunk-column chunk-index chunk-size columns count crc function lock
425             modulo use-index offset optimize-xor chunk-size-limit probability separator
426             save-since single-chunk since since-column sleep sleep-coef trim wait where
427
428           Each of these columns corresponds to the long form of a command-
429           line option.  Each column should be NULL-able.  Column names with
430           hyphens should be enclosed in backticks (e.g. `chunk-size`) when
431           the table is created.  The data type does not matter, but it's
432           suggested you use a sensible data type to prevent garbage data.
433
434           When "mk-table-checksum" checksums a table, it will look for a
435           matching entry in this table.  Any column that has a defined value
436           will override the corresponding command-line argument for the table
437           being currently processed.  In this way it is possible to specify
438           custom command-line arguments for any table.
439
440           If you add columns to the table that aren't in the above list of
441           allowable columns, it's an error.  The exceptions are "db", "tbl",
442           and "ts".  The "ts" column can be used as a timestamp for easy
443           visibility into the last time the "since" column was updated with
444           "--save-since".
445
446           This table is assumed to be located on the first server given on
447           the command-line.
448
449       --ask-pass
450           group: Connection
451
452           Prompt for a password when connecting to MySQL.
453
454       --check-interval
455           type: time; group: Throttle; default: 1s
456
457           How often to check for slave lag if "--check-slave-lag" is given.
458
459       --[no]check-replication-filters
460           default: yes; group: Safety
461
462           Do not "--replicate" if any replication filters are set.  When
463           --replicate is specified, mk-table-checksum tries to detect slaves
464           and look for options that filter replication, such as
465           binlog_ignore_db and replicate_do_db.  If it finds any such
466           filters, it aborts with an error.  Replication filtering makes it
467           impossible to be sure that the checksum queries won't break
468           replication or simply fail to replicate.  If you are sure that it's
469           OK to run the checksum queries, you can negate this option to
470           disable the checks.  See also "--replicate-database".
471
472       --check-slave-lag
473           type: DSN; group: Throttle
474
475           Pause checksumming until the specified slave's lag is less than
476           "--max-lag".
477
478           If this option is specified and "--throttle-method" is set to
479           "slavelag" then "--throttle-method" only checks this slave.
480
481       --checksum
482           group: Output
483
484           Print checksums and table names in the style of md5sum (disables
485           "--[no]count").
486
487           Makes the output behave more like the output of "md5sum".  The
488           checksum is first on the line, followed by the host, database,
489           table, and chunk number, concatenated with dots.
490
491       --chunk-column
492           type: string
493
494           Prefer this column for dividing tables into chunks.  By default,
495           mk-table-checksum chooses the first suitable column for each table,
496           preferring to use the primary key.  This option lets you specify a
497           preferred column, which mk-table-checksum uses if it exists in the
498           table and is chunkable.  If not, then mk-table-checksum will revert
499           to its default behavior.  Be careful when using this option; a poor
500           choice could cause bad performance.  This is probably best to use
501           when you are checksumming only a single table, not an entire
502           server.  See also "--chunk-index".
503
504       --chunk-index
505           type: string
506
507           Prefer this index for chunking tables.  By default, mk-table-
508           checksum chooses an appropriate index for the "--chunk-column"
509           (even if it chooses the chunk column automatically).  This option
510           lets you specify the index you prefer.  If the index doesn't exist,
511           then mk-table-checksum will fall back to its default behavior.  mk-
512           table-checksum adds the index to the checksum SQL statements in a
513           "FORCE INDEX" clause.  Be careful when using this option; a poor
514           choice of index could cause bad performance.  This is probably best
515           to use when you are checksumming only a single table, not an entire
516           server.
517
518       --chunk-size
519           type: string
520
521           Approximate number of rows or size of data to checksum at a time.
522           Allowable suffixes are k, M, G. Disallows "--algorithm CHECKSUM".
523
524           If you specify a chunk size, mk-table-checksum will try to find an
525           index that will let it split the table into ranges of approximately
526           "--chunk-size" rows, based on the table's index statistics.
527           Currently only numeric and date types can be chunked.
528
529           If the table is chunkable, mk-table-checksum will checksum each
530           range separately with parameters in the checksum query's WHERE
531           clause.  If mk-table-checksum cannot find a suitable index, it will
532           do the entire table in one chunk as though you had not specified
533           "--chunk-size" at all.  Each table is handled individually, so some
534           tables may be chunked and others not.
535
536           The chunks will be approximately sized, and depending on the
537           distribution of values in the indexed column, some chunks may be
538           larger than the value you specify.
539
540           If you specify a suffix (one of k, M or G), the parameter is
541           treated as a data size rather than a number of rows.  The output of
542           SHOW TABLE STATUS is then used to estimate the amount of data the
543           table contains, and convert that to a number of rows.
544
545       --chunk-size-limit
546           type: float; default: 2.0; group: Safety
547
548           Do not checksum chunks with this many times more rows than
549           "--chunk-size".
550
551           When "--chunk-size" is given it specifies an ideal size for each
552           chunk of a chunkable table (in rows; size values are converted to
553           rows).  Before checksumming each chunk, mk-table-checksum checks
554           how many rows are in the chunk with EXPLAIN.  If the number of rows
555           reported by EXPLAIN is this many times greater than "--chunk-size",
556           then the chunk is skipped.
557
558           For example, if you specify "--chunk-size" 100 and a chunk has 150
559           rows, then it is checksummed with the default "--chunk-size-limit"
560           value 2.0 because 150 is less than 100 * 2.0.  But if the chunk has
561           205 rows, then it is not checksummed because 205 is greater than
562           100 * 2.0.
563
564           The minimum value for this option is 1 which means that no chunk
565           can be any larger than "--chunk-size".  You probably don't want to
566           specify 1 because rows reported by EXPLAIN are estimates which can
567           be greater than or less than the real number of rows in the chunk.
568           If too many chunks are skipped because they are oversize, you might
569           want to specify a value larger than 2.
570
571           You can disable oversize chunk checking by specifying
572           "--chunk-size-limit" 0.
573
574           See also "--unchunkable-tables".
575
576       --columns
577           type: array; group: Filter
578
579           Checksum only this comma-separated list of columns.
580
581       --config
582           type: Array; group: Config
583
584           Read this comma-separated list of config files; if specified, this
585           must be the first option on the command line.
586
587       --[no]count
588           Count rows in tables.  This is built into ACCUM and BIT_XOR, but
589           requires an extra query for CHECKSUM.
590
591           This is disabled by default to avoid an extra COUNT(*) query when
592           "--algorithm" is CHECKSUM.  If you have only MyISAM tables and live
593           checksums are enabled, both CHECKSUM and COUNT will be very fast,
594           but otherwise you may want to use one of the other algorithms.
595
596       --[no]crc
597           default: yes
598
599           Do a CRC (checksum) of tables.
600
601           Take the checksum of the rows as well as their count.  This is
602           enabled by default.  If you disable it, you'll just get COUNT(*)
603           queries.
604
605       --create-replicate-table
606           Create the replicate table given by "--replicate" if it does not
607           exist.
608
609           Normally, if the replicate table given by "--replicate" does not
610           exist, "mk-table-checksum" will die. With this option, however,
611           "mk-table-checksum" will create the replicate table for you, using
612           the database.table name given to "--replicate".
613
614           The structure of the replicate table is the same as the suggested
615           table mentioned in "--replicate". Note that since ENGINE is not
616           specified, the replicate table will use the server's default
617           storage engine.  If you want to use a different engine, you need to
618           create the table yourself.
619
620       --databases
621           short form: -d; type: hash; group: Filter
622
623           Only checksum this comma-separated list of databases.
624
625       --defaults-file
626           short form: -F; type: string; group: Connection
627
628           Only read mysql options from the given file.  You must give an
629           absolute pathname.
630
631       --empty-replicate-table
632           Empty table given by "--replicate" before starting.
633
634           Issues a DELETE against the table given by "--replicate" before
635           beginning work.  Ignored if "--replicate" is not specified.  This
636           can be useful to remove entries related to tables that no longer
637           exist, or just to clean out the results of a previous run.
638
639       --engines
640           short form: -e; type: hash; group: Filter
641
642           Do only this comma-separated list of storage engines.
643
644       --explain
645           group: Output
646
647           Show, but do not execute, checksum queries (disables
648           "--empty-replicate-table").
649
650       --explain-hosts
651           group: Help
652
653           Print connection information and exit.
654
655           Print out a list of hosts to which mk-table-checksum will connect,
656           with all the various connection options, and exit.  See "SPECIFYING
657           HOSTS".
658
659       --float-precision
660           type: int
661
662           Precision for "FLOAT" and "DOUBLE" column comparisons.
663
664           If you specify this option, FLOAT and DOUBLE columns will be
665           rounded to the specified number of digits after the decimal point
666           for the checksum.  This can avoid checksum mismatches due to
667           different floating-point representations of the same values on
668           different MySQL versions and hardware.
669
670       --function
671           type: string
672
673           Hash function for checksums (FNV1A_64, MURMUR_HASH, SHA1, MD5,
674           CRC32, etc).
675
676           You can use this option to choose the cryptographic hash function
677           used for "--algorithm"=ACCUM or "--algorithm"=BIT_XOR.  The default
678           is to use "CRC32", but "MD5" and "SHA1" also work, and you can use
679           your own function, such as a compiled UDF, if you wish.  Whatever
680           function you specify is run in SQL, not in Perl, so it must be
681           available to MySQL.
682
683           The "FNV1A_64" UDF mentioned in the benchmarks is much faster than
684           "MD5".  The C++ source code is distributed with Maatkit.  It is
685           very simple to compile and install; look at the header in the
686           source code for instructions.  If it is installed, it is preferred
687           over "MD5".  You can also use the MURMUR_HASH function if you
688           compile and install that as a UDF; the source is also distributed
689           with Maatkit, and it is faster and has better distribution than
690           FNV1A_64.
691
692       --help
693           group: Help
694
695           Show help and exit.
696
697       --ignore-columns
698           type: array; group: Filter
699
700           Ignore this comma-separated list of columns when calculating the
701           checksum.
702
703           This option only affects the checksum when using the ACCUM or
704           BIT_XOR "--algorithm".
705
706       --ignore-databases
707           type: hash; group: Filter
708
709           Ignore this comma-separated list of databases.
710
711       --ignore-engines
712           type: Hash; default: FEDERATED,MRG_MyISAM; group: Filter
713
714           Ignore this comma-separated list of storage engines.
715
716       --ignore-tables
717           type: hash; group: Filter
718
719           Ignore this comma-separated list of tables.
720
721           Table names may be qualified with the database name.
722
723       --lock
724           Lock on master until done on slaves (implies "--slave-lag").
725
726           This option can help you to get a consistent read on a master and
727           many slaves.  If you specify this option, mk-table-checksum will
728           lock the table on the first server on the command line, which it
729           assumes to be the master.  It will keep this lock until the
730           checksums complete on the other servers.
731
732           This option isn't very useful by itself, so you probably want to
733           use "--wait" instead.
734
735           Note: if you're checksumming a slave against its master, you should
736           use "--replicate".  In that case, there's no need for locking,
737           waiting, or any of that.
738
739       --max-lag
740           type: time; group: Throttle; default: 1s
741
742           Suspend checksumming if the slave given by "--check-slave-lag"
743           lags.
744
745           This option causes mk-table-checksum to look at the slave every
746           time it's about to checksum a chunk.  If the slave's lag is greater
747           than the option's value, or if the slave isn't running (so its lag
748           is NULL), mk-table-checksum sleeps for "--check-interval" seconds
749           and then looks at the lag again.  It repeats until the slave is
750           caught up, then proceeds to checksum the chunk.
751
752           This option is useful to let you checksum data as fast as the
753           slaves can handle it, assuming the slave you directed mk-table-
754           checksum to monitor is representative of all the slaves that may be
755           replicating from this server.  It should eliminate the need for
756           "--sleep" or "--sleep-coef".
757
758       --modulo
759           type: int
760
761           Do only every Nth chunk on chunked tables.
762
763           This option lets you checksum only some chunks of the table.  This
764           is a useful alternative to "--probability" when you want to be sure
765           you get full coverage in some specified number of runs; for
766           example, you can do only every 7th chunk, and then use "--offset"
767           to rotate the modulo every day of the week.
768
769           Just like with "--probability", a table that cannot be chunked is
770           done every time.
771
772       --offset
773           type: string; default: 0
774
775           Modulo offset expression for use with "--modulo".
776
777           The argument may be an SQL expression, such as "WEEKDAY(NOW())"
778           (which returns a number from 0 through 6).  The argument is
779           evaluated by MySQL.  The result is used as follows: if chunk_num %
780           "--modulo" == "--offset", the chunk will be checksummed.
781
782       --[no]optimize-xor
783           default: yes
784
785           Optimize BIT_XOR with user variables.
786
787           This option specifies to use user variables to reduce the number of
788           times each row must be passed through the cryptographic hash
789           function when you are using the BIT_XOR algorithm.
790
791           With the optimization, the queries look like this in pseudo-code:
792
793             SELECT CONCAT(
794                BIT_XOR(SLICE_OF(@user_variable)),
795                BIT_XOR(SLICE_OF(@user_variable)),
796                ...
797                BIT_XOR(SLICE_OF(@user_variable := HASH(col1, col2... colN))));
798
799           The exact positioning of user variables and calls to the hash
800           function is determined dynamically, and will vary between MySQL
801           versions.  Without the optimization, it looks like this:
802
803             SELECT CONCAT(
804                BIT_XOR(SLICE_OF(MD5(col1, col2... colN))),
805                BIT_XOR(SLICE_OF(MD5(col1, col2... colN))),
806                ...
807                BIT_XOR(SLICE_OF(MD5(col1, col2... colN))));
808
809           The difference is the number of times all the columns must be
810           mashed together and fed through the hash function.  If you are
811           checksumming really large columns, such as BLOB or TEXT columns,
812           this might make a big difference.
813
814       --password
815           short form: -p; type: string; group: Connection
816
817           Password to use when connecting.
818
819       --pid
820           type: string
821
822           Create the given PID file.  The file contains the process ID of the
823           script.  The PID file is removed when the script exits.  Before
824           starting, the script checks if the PID file already exists.  If it
825           does not, then the script creates and writes its own PID to it.  If
826           it does, then the script checks the following: if the file contains
827           a PID and a process is running with that PID, then the script dies;
828           or, if there is no process running with that PID, then the script
829           overwrites the file with its own PID and starts; else, if the file
830           contains no PID, then the script dies.
831
832       --port
833           short form: -P; type: int; group: Connection
834
835           Port number to use for connection.
836
837       --probability
838           type: int; default: 100
839
840           Checksums will be run with this percent probability.
841
842           This is an integer between 1 and 100.  If 100, every chunk of every
843           table will certainly be checksummed.  If less than that, there is a
844           chance that some chunks of some tables will be skipped.  This is
845           useful for routine jobs designed to randomly sample bits of tables
846           without checksumming the whole server.  By default, if a table is
847           not chunkable, it will be checksummed every time even when the
848           probability is less than 100.  You can override this with
849           "--single-chunk".
850
851           See also "--modulo".
852
853       --quiet
854           short form: -q; group: Output
855
856           Do not print checksum results.
857
858       --recheck
859           Re-checksum chunks that "--replicate-check" found to be different.
860
861       --recurse
862           group: Throttle
863
864           Number of levels to recurse in the hierarchy when discovering
865           slaves.  Default is infinite.
866
867           See "--recursion-method".
868
869       --recursion-method
870           type: string
871
872           Preferred recursion method for discovering slaves.
873
874           Possible methods are:
875
876             METHOD       USES
877             ===========  ================
878             processlist  SHOW PROCESSLIST
879             hosts        SHOW SLAVE HOSTS
880
881           The processlist method is preferred because SHOW SLAVE HOSTS is not
882           reliable.  However, the hosts method is required if the server uses
883           a non-standard port (not 3306).  Usually mk-table-checksum does the
884           right thing and finds the slaves, but you may give a preferred
885           method and it will be used first.  If it doesn't find any slaves,
886           the other methods will be tried.
887
888       --replicate
889           type: string
890
891           Replicate checksums to slaves (disallows --algorithm CHECKSUM).
892
893           This option enables a completely different checksum strategy for a
894           consistent, lock-free checksum across a master and its slaves.
895           Instead of running the checksum queries on each server, you run
896           them only on the master.  You specify a table, fully qualified in
897           db.table format, to insert the results into.  The checksum queries
898           will insert directly into the table, so they will be replicated
899           through the binlog to the slaves.
900
901           When the queries are finished replicating, you can run a simple
902           query on each slave to see which tables have differences from the
903           master.  With the "--replicate-check" option, mk-table-checksum can
904           run the query for you to make it even easier.  See "CONSISTENT
905           CHECKSUMS" for details.
906
907           If you find tables that have differences, you can use the chunk
908           boundaries in a WHERE clause with mk-table-sync to help repair them
909           more efficiently.  See mk-table-sync for details.
910
911           The table must have at least these columns: db, tbl, chunk,
912           boundaries, this_crc, master_crc, this_cnt, master_cnt.  The table
913           may be named anything you wish.  Here is a suggested table
914           structure, which is automatically used for
915           "--create-replicate-table" (MAGIC_create_replicate):
916
917             CREATE TABLE checksum (
918                db         char(64)     NOT NULL,
919                tbl        char(64)     NOT NULL,
920                chunk      int          NOT NULL,
921                boundaries char(100)    NOT NULL,
922                this_crc   char(40)     NOT NULL,
923                this_cnt   int          NOT NULL,
924                master_crc char(40)         NULL,
925                master_cnt int              NULL,
926                ts         timestamp    NOT NULL,
927                PRIMARY KEY (db, tbl, chunk)
928             );
929
930           Be sure to choose an appropriate storage engine for the checksum
931           table.  If you are checksumming InnoDB tables, for instance, a
932           deadlock will break replication if the checksum table is non-
933           transactional, because the transaction will still be written to the
934           binlog.  It will then replay without a deadlock on the slave and
935           break replication with "different error on master and slave."  This
936           is not a problem with mk-table-checksum, it's a problem with MySQL
937           replication, and you can read more about it in the MySQL manual.
938
939           This works only with statement-based replication (mk-table-checksum
940           will switch the binlog format to STATEMENT for the duration of the
941           session if your server uses row-based replication).
942
943           In contrast to running the tool against multiple servers at once,
944           using this option eliminates the complexities of synchronizing
945           checksum queries across multiple servers, which normally requires
946           locking and unlocking, waiting for master binlog positions, and so
947           on.  Thus, it disables "--lock", "--wait", and "--slave-lag" (but
948           not "--check-slave-lag", which is a way to throttle the execution
949           speed).
950
951           The checksum queries actually do a REPLACE into this table, so
952           existing rows need not be removed before running.  However, you may
953           wish to do this anyway to remove rows related to tables that don't
954           exist anymore.  The "--empty-replicate-table" option does this for
955           you.
956
957           Since the table must be qualified with a database (e.g.
958           "db.checksums"), mk-table-checksum will only USE this database.
959           This may be important if any replication options are set because it
960           could affect whether or not changes to the table are replicated.
961
962           If the slaves have any --replicate-do-X or --replicate-ignore-X
963           options, you should be careful not to checksum any databases or
964           tables that exist on the master and not the slaves.  Changes to
965           such tables may not normally be executed on the slaves because of
966           the --replicate options, but the checksum queries modify the
967           contents of the table that stores the checksums, not the tables
968           whose data you are checksumming.  Therefore, these queries will be
969           executed on the slave, and if the table or database you're
970           checksumming does not exist, the queries will cause replication to
971           fail.  For more information on replication rules, see
972           http://dev.mysql.com/doc/en/replication-rules.html
973           <http://dev.mysql.com/doc/en/replication-rules.html>.
974
975           The table specified by "--replicate" will never be checksummed
976           itself.
977
978       --replicate-check
979           type: int
980
981           Check results in "--replicate" table, to the specified depth.
982
983           Recursively finds differences recorded in the table given by
984           "--replicate".  Recurses to the depth you specify: 0 is no
985           recursion (check only the server you specify), 1 is check the
986           server and its slaves, 2 is check the slaves of its slaves, and so
987           on.
988
989           It finds differences by running the query shown in "CONSISTENT
990           CHECKSUMS", and prints results, then exits after printing.  This is
991           just a convenient way of running the query so you don't have to do
992           it manually.
993
994           The output is one informational line per slave host, followed by
995           the results of the query, if any.  If "--quiet" is specified, there
996           is no output.  If there are no differences between the master and
997           any slave, there is no output.  If any slave has chunks that differ
998           from the master, mk-table-checksum's exit status is 1; otherwise it
999           is 0.
1000
1001           This option makes "mk-table-checksum" look for slaves by running
1002           "SHOW PROCESSLIST".  If it finds connections that appear to be from
1003           slaves, it derives connection information for each slave with the
1004           same default-and-override method described in "SPECIFYING HOSTS".
1005
1006           If "SHOW PROCESSLIST" doesn't return any rows, "mk-table-checksum"
1007           looks at "SHOW SLAVE HOSTS" instead.  The host and port, and user
1008           and password if available, from "SHOW SLAVE HOSTS" are combined
1009           into a DSN and used as the argument.  This requires slaves to be
1010           configured with "report-host", "report-port" and so on.
1011
1012           This requires the @@SERVER_ID system variable, so it works only on
1013           MySQL 3.23.26 or newer.
1014
1015       --replicate-database
1016           type: string
1017
1018           "USE" only this database with "--replicate".  By default, mk-table-
1019           checksum executes USE to set its default database to the database
1020           that contains the table it's currently working on.  It changes its
1021           default database as it works on different tables.  This is is a
1022           best effort to avoid problems with replication filters such as
1023           binlog_ignore_db and replicate_ignore_db.  However, replication
1024           filters can create a situation where there simply is no one right
1025           way to do things.  Some statements might not be replicated, and
1026           others might cause replication to fail on the slaves.  In such
1027           cases, it is up to the user to specify a safe default database.
1028           This option specifies a default database that mk-table-checksum
1029           selects with USE, and never changes afterwards.  See also
1030           <L"--[no]check-replication-filters">.
1031
1032       --resume
1033           type: string
1034
1035           Resume checksum using given output file from a previously
1036           interrupted run.
1037
1038           The given output file should be the literal output from a previous
1039           run of "mk-table-checksum".  For example:
1040
1041              mk-table-checksum host1 host2 -C 100 > checksum_results.txt
1042              mk-table-checksum host1 host2 -C 100 --resume checksum_results.txt
1043
1044           The command line options given to the first run and the resumed run
1045           must be identical (except, of course, for --resume).  If they are
1046           not, the result will be unpredictible and probably wrong.
1047
1048           "--resume" does not work with "--replicate"; for that, use
1049           "--resume-replicate".
1050
1051       --resume-replicate
1052           Resume "--replicate".
1053
1054           This option resumes a previous checksum operation using
1055           "--replicate".  It is like "--resume" but does not require an
1056           output file.  Instead, it uses the checksum table given to
1057           "--replicate" to determine where to resume the checksum operation.
1058
1059       --save-since
1060           When "--arg-table" and "--since" are given, save the current
1061           "--since" value into that table's "since" column after
1062           checksumming.  In this way you can incrementally checksum tables by
1063           starting where the last one finished.
1064
1065           The value to be saved could be the current timestamp, or it could
1066           be the maximum existing value of the column given by
1067           "--since-column".  It depends on what options are in effect.  See
1068           the description of "--since" to see how timestamps are different
1069           from ordinary values.
1070
1071       --schema
1072           Checksum "SHOW CREATE TABLE" intead of table data.
1073
1074       --separator
1075           type: string; default: #
1076
1077           The separator character used for CONCAT_WS().
1078
1079           This character is used to join the values of columns when
1080           checksumming with "--algorithm" of BIT_XOR or ACCUM.
1081
1082       --set-vars
1083           type: string; default: wait_timeout=10000; group: Connection
1084
1085           Set these MySQL variables.  Immediately after connecting to MySQL,
1086           this string will be appended to SET and executed.
1087
1088       --since
1089           type: string
1090
1091           Checksum only data newer than this value.
1092
1093           If the table is chunk-able or nibble-able, this value will apply to
1094           the first column of the chunked or nibbled index.
1095
1096           This is not too different to "--where", but instead of universally
1097           applying a WHERE clause to every table, it selectively finds the
1098           right column to use and applies it only if such a column is found.
1099           See also "--since-column".
1100
1101           The argument may be an expression, which is evaluated by MySQL.
1102           For example, you can specify "CURRENT_DATE - INTERVAL 7 DAY" to get
1103           the date of one week ago.
1104
1105           A special bit of extra magic: if the value is temporal (looks like
1106           a date or datetime), then the table is checksummed only if the
1107           create time (or last modified time, for tables that report the last
1108           modified time, such as MyISAM tables) is newer than the value.  In
1109           this sense it's not applied as a WHERE clause at all.
1110
1111       --since-column
1112           type: string
1113
1114           The column name to be used for "--since".
1115
1116           The default is for the tool to choose the best one automatically.
1117           If you specify a value, that will be used if possible; otherwise
1118           the best auto-determined one; otherwise none.  If the column
1119           doesn't exist in the table, it is just ignored.
1120
1121       --single-chunk
1122           Permit skipping with "--probability" if there is only one chunk.
1123
1124           Normally, if a table isn't split into many chunks, it will always
1125           be checksummed regardless of "--probability".  This setting lets
1126           the probabilistic behavior apply to tables that aren't divided into
1127           chunks.
1128
1129       --slave-lag
1130           group: Output
1131
1132           Report replication delay on the slaves.
1133
1134           If this option is enabled, the output will show how many seconds
1135           behind the master each slave is.  This can be useful when you want
1136           a fast, parallel, non-blocking checksum, and you know your slaves
1137           might be delayed relative to the master.  You can inspect the
1138           results and make an educated guess whether any discrepancies on the
1139           slave are due to replication delay instead of corrupt data.
1140
1141           If you're using "--replicate", a slave that is delayed relative to
1142           the master does not invalidate the correctness of the results, so
1143           this option is disabled.
1144
1145       --sleep
1146           type: int; group: Throttle
1147
1148           Sleep time between checksums.
1149
1150           If this option is specified, mk-table-checksum will sleep the
1151           specified number of seconds between checksums.  That is, it will
1152           sleep between every table, and if you specify "--chunk-size", it
1153           will also sleep between chunks.
1154
1155           This is a very crude way to throttle checksumming; see
1156           "--sleep-coef" and "--check-slave-lag" for techniques that permit
1157           greater control.
1158
1159       --sleep-coef
1160           type: float; group: Throttle
1161
1162           Calculate "--sleep" as a multiple of the last checksum time.
1163
1164           If this option is specified, mk-table-checksum will sleep the
1165           amount of time elapsed during the previous checksum, multiplied by
1166           the specified coefficient.  This option is ignored if "--sleep" is
1167           specified.
1168
1169           This is a slightly more sophisticated way to throttle checksum
1170           speed: sleep a varying amount of time between chunks, depending on
1171           how long the chunks are taking.  Even better is to use
1172           "--check-slave-lag" if you're checksumming master/slave
1173           replication.
1174
1175       --socket
1176           short form: -S; type: string; group: Connection
1177
1178           Socket file to use for connection.
1179
1180       --tab
1181           group: Output
1182
1183           Print tab-separated output, not column-aligned output.
1184
1185       --tables
1186           short form: -t; type: hash; group: Filter
1187
1188           Do only this comma-separated list of tables.
1189
1190           Table names may be qualified with the database name.
1191
1192       --throttle-method
1193           type: string; default: none; group: Throttle
1194
1195           Throttle checksumming when doing "--replicate".
1196
1197           At present there is only one method: "slavelag".  When
1198           "--replicate" is used, mk-table-checksum automatically sets
1199           "--throttle-method" to "slavelag" and discovers every slave and
1200           throttles checksumming if any slave lags more than "--max-lag".
1201           Specify "-throttle-method none" to disable this behavior
1202           completely, or specify "--check-slave-lag" and mk-table-checksum
1203           will only check that slave.
1204
1205           See also "--recurse" and "--recursion-method".
1206
1207       --trim
1208           Trim "VARCHAR" columns (helps when comparing 4.1 to >= 5.0).
1209
1210           This option adds a "TRIM()" to "VARCHAR" columns in "BIT_XOR" and
1211           "ACCUM" modes.
1212
1213           This is useful when you don't care about the trailing space
1214           differences between MySQL versions which vary in their handling of
1215           trailing spaces. MySQL 5.0 and later all retain trailing spaces in
1216           "VARCHAR", while previous versions would remove them.
1217
1218       --unchunkable-tables
1219           group: Safety
1220
1221           Checksum tables that cannot be chunked when "--chunk-size" is
1222           specified.
1223
1224           By default mk-table-checksum will not checksum a table that cannot
1225           be chunked when "--chunk-size" is specified because this might
1226           result in a huge, non-chunkable table being checksummed in one
1227           huge, memory-intensive chunk.
1228
1229           Specifying this option allows checksumming tables that cannot be
1230           chunk.  Be careful when using this option!  Make sure any non-
1231           chunkable tables are not so large that they will cause the tool to
1232           consume too much memory or CPU.
1233
1234           See also "--chunk-size-limit".
1235
1236       --[no]use-index
1237           default: yes
1238
1239           Add FORCE INDEX hints to SQL statements.
1240
1241           By default "mk-table-checksum" adds an index hint ("FORCE INDEX"
1242           for MySQL v4.0.9 and newer, "USE INDEX" for older MySQL versions)
1243           to each SQL statement to coerce MySQL into using the
1244           "--chunk-index" (whether the index is specified by the option or
1245           auto-detected).  Specifying "--no-use-index" causes
1246           "mk-table-checksum" to omit index hints.
1247
1248       --user
1249           short form: -u; type: string; group: Connection
1250
1251           User for login if not current user.
1252
1253       --[no]verify
1254           default: yes
1255
1256           Verify checksum compatibility across servers.
1257
1258           This option runs a trivial checksum on all servers to ensure they
1259           have compatible CONCAT_WS() and cryptographic hash functions.
1260
1261           Versions of MySQL before 4.0.14 will skip empty strings and NULLs
1262           in CONCAT_WS, and others will only skip NULLs.  The two kinds of
1263           behavior will produce different results if you have any columns
1264           containing the empty string in your table.  If you know you don't
1265           (for instance, all columns are integers), you can safely disable
1266           this check and you will get a reliable checksum even on servers
1267           with different behavior.
1268
1269       --version
1270           group: Help
1271
1272           Show version and exit.
1273
1274       --wait
1275           short form: -w; type: time
1276
1277           Wait this long for slaves to catch up to their master (implies
1278           "--lock" "--slave-lag").
1279
1280           Note: the best way to verify that a slave is in sync with its
1281           master is to use "--replicate" instead.  The "--wait" option is
1282           really only useful if you're trying to compare masters and slaves
1283           without using "--replicate", which is possible but complex and less
1284           efficient in some ways.
1285
1286           This option helps you get a consistent checksum across a master
1287           server and its slaves.  It combines locking and waiting to
1288           accomplish this.  First it locks the table on the master (the first
1289           server on the command line).  Then it finds the master's binlog
1290           position.  Checksums on slaves will be deferred until they reach
1291           the same binlog position.
1292
1293           The argument to the option is the number of seconds to wait for the
1294           slaves to catch up to the master.  It is actually the argument to
1295           MASTER_POS_WAIT().  If the slaves don't catch up to the master
1296           within this time, they will unblock and go ahead with the checksum.
1297           You can tell whether this happened by examining the STAT column in
1298           the output, which is the return value of MASTER_POS_WAIT().
1299
1300       --where
1301           type: string
1302
1303           Do only rows matching this "WHERE" clause (disallows "--algorithm"
1304           CHECKSUM).
1305
1306           You can use this option to limit the checksum to only part of the
1307           table.  This is particularly useful if you have append-only tables
1308           and don't want to constantly re-check all rows; you could run a
1309           daily job to just check yesterday's rows, for instance.
1310
1311           This option is much like the -w option to mysqldump.  Do not
1312           specify the WHERE keyword.  You may need to quote the value.  Here
1313           is an example:
1314
1315             mk-table-checksum --where "foo=bar"
1316
1317       --[no]zero-chunk
1318           default: yes
1319
1320           Add a chunk for rows with zero or zero-equivalent values.  The only
1321           has an effect when "--chunk-size" is specified.  The purpose of the
1322           zero chunk is to capture a potentially large number of zero values
1323           that would imbalance the size of the first chunk.  For example, if
1324           a lot of negative numbers were inserted into an unsigned integer
1325           column causing them to be stored as zeros, then these zero values
1326           are captured by the zero chunk instead of the first chunk and all
1327           its non-zero values.
1328

DSN OPTIONS

1330       These DSN options are used to create a DSN.  Each option is given like
1331       "option=value".  The options are case-sensitive, so P and p are not the
1332       same option.  There cannot be whitespace before or after the "=" and if
1333       the value contains whitespace it must be quoted.  DSN options are
1334       comma-separated.  See the maatkit manpage for full details.
1335
1336       ·   A
1337
1338           dsn: charset; copy: yes
1339
1340           Default character set.
1341
1342       ·   D
1343
1344           dsn: database; copy: yes
1345
1346           Default database.
1347
1348       ·   F
1349
1350           dsn: mysql_read_default_file; copy: yes
1351
1352           Only read default options from the given file
1353
1354       ·   h
1355
1356           dsn: host; copy: yes
1357
1358           Connect to host.
1359
1360       ·   p
1361
1362           dsn: password; copy: yes
1363
1364           Password to use when connecting.
1365
1366       ·   P
1367
1368           dsn: port; copy: yes
1369
1370           Port number to use for connection.
1371
1372       ·   S
1373
1374           dsn: mysql_socket; copy: yes
1375
1376           Socket file to use for connection.
1377
1378       ·   u
1379
1380           dsn: user; copy: yes
1381
1382           User for login if not current user.
1383

DOWNLOADING

1385       You can download Maatkit from Google Code at
1386       <http://code.google.com/p/maatkit/>, or you can get any of the tools
1387       easily with a command like the following:
1388
1389          wget http://www.maatkit.org/get/toolname
1390          or
1391          wget http://www.maatkit.org/trunk/toolname
1392
1393       Where "toolname" can be replaced with the name (or fragment of a name)
1394       of any of the Maatkit tools.  Once downloaded, they're ready to run; no
1395       installation is needed.  The first URL gets the latest released version
1396       of the tool, and the second gets the latest trunk code from Subversion.
1397

ENVIRONMENT

1399       The environment variable "MKDEBUG" enables verbose debugging output in
1400       all of the Maatkit tools:
1401
1402          MKDEBUG=1 mk-....
1403

SYSTEM REQUIREMENTS

1405       You need Perl, DBI, DBD::mysql, and some core packages that ought to be
1406       installed in any reasonably new version of Perl.
1407

BUGS

1409       For list of known bugs see
1410       http://www.maatkit.org/bugs/mk-table-checksum
1411       <http://www.maatkit.org/bugs/mk-table-checksum>.
1412
1413       Please use Google Code Issues and Groups to report bugs or request
1414       support: <http://code.google.com/p/maatkit/>.  You can also join
1415       #maatkit on Freenode to discuss Maatkit.
1416
1417       Please include the complete command-line used to reproduce the problem
1418       you are seeing, the version of all MySQL servers involved, the complete
1419       output of the tool when run with "--version", and if possible,
1420       debugging output produced by running with the "MKDEBUG=1" environment
1421       variable.
1422

COPYRIGHT, LICENSE AND WARRANTY

1424       This program is copyright 2007-2010 Baron Schwartz.  Feedback and
1425       improvements are welcome.
1426
1427       THIS PROGRAM IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
1428       WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
1429       MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
1430
1431       This program is free software; you can redistribute it and/or modify it
1432       under the terms of the GNU General Public License as published by the
1433       Free Software Foundation, version 2; OR the Perl Artistic License.  On
1434       UNIX and similar systems, you can issue `man perlgpl' or `man
1435       perlartistic' to read these licenses.
1436
1437       You should have received a copy of the GNU General Public License along
1438       with this program; if not, write to the Free Software Foundation, Inc.,
1439       59 Temple Place, Suite 330, Boston, MA  02111-1307  USA.
1440

SEE ALSO

1442       See also mk-checksum-filter and mk-table-sync.
1443

AUTHOR

1445       Baron "Xaprb" Schwartz
1446

ABOUT MAATKIT

1448       This tool is part of Maatkit, a toolkit for power users of MySQL.
1449       Maatkit was created by Baron Schwartz; Baron and Daniel Nichter are the
1450       primary code contributors.  Both are employed by Percona.  Financial
1451       support for Maatkit development is primarily provided by Percona and
1452       its clients.
1453

ACKNOWLEDGEMENTS

1455       This is an incomplete list.  My apologies for omissions or
1456       misspellings.
1457
1458       Claus Jeppesen, Francois Saint-Jacques, Giuseppe Maxia, Heikki Tuuri,
1459       James Briggs, Martin Friebe, Sergey Zhuravlev,
1460

VERSION

1462       This manual page documents Ver 1.2.17 Distrib 6839 $Revision: 6834 $.
1463
1464
1465
1466perl v5.12.1                      2010-08-01              MK-TABLE-CHECKSUM(1)
Impressum