pt-archiver doesn't honor b=1 flag to create SQL_LOG_BIN statement

Bug #903387 reported by maxim.volkov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Toolkit moved to https://jira.percona.com/projects/PT
Invalid
Undecided
Daniel Nichter
2.0
Invalid
Undecided
Daniel Nichter
2.1
Invalid
Undecided
Daniel Nichter

Bug Description

Version: percona-toolkit-1.0.1-1

Full command:

pt-archiver \
--source h=localhost,D=database,t=table_I,b=1,i=index \
--dest h=localhost,D=database,t=table_II,b=1,i=index \
--columns column1,column2,column3,column4,column5 \
--where "changed_when < '2011-12-01 00:00:00'" --limit 1000 --commit-each \
--nocheck-columns --replace --commit-each --bulk-insert --bulk-delete \
--statistics \
--no-check-charset \
--file '/tmp/mysql/%Y-%m-%d-%D_%H:%i:%s.%t'

Issue: No ",b=1" nor ",b=true" flags won't create expected SET SQL_LOG_BIN = 0; statement neither with --dry-run nor with actual run.

tags: added: log-bin pt-archiver
tags: added: risk
Changed in percona-toolkit:
status: New → Triaged
Changed in percona-toolkit:
milestone: none → 2.1.3
Changed in percona-toolkit:
importance: Undecided → High
Changed in percona-toolkit:
status: Triaged → In Progress
assignee: nobody → Daniel Nichter (daniel-nichter)
Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

I cannot reproduce this. With 1.0 and 2.1 I see SET SQL_LOG_BIN=0 in the general log when running "pt-archiver --source F=/tmp/12345/my.sandbox.cnf,D=sakila,t=c,b=1 --purge --where 1=1 --no-check-charset".

How are you verifying that SET SQL_LOG_BIN=0 is _not_ being set, Maxim?

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

Here's the relevant code:

      if ( $table->{b} ) {
         $dbh->do("SET SQL_LOG_BIN=0");
      }

So b=<any true value> should work.

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

Maxium, can you reproduce this? See my previous comments.

Revision history for this message
maxim.volkov (maxim.volkov) wrote :

Daniel,

The latest version of pt-archiver (2.1) did successfully produced expected result.

Initial verification was by running on a test table, on a master. The table on a master and slave initially was identical. The expected result was - data would be removed on a master and still present on a slave. The actual result - data was removed on both sources.
Running with "--dry-run" didn't produce SET SQL_LOG_BIN=0 either.

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

Thanks Maxim. This is tested now:

ok 26 - Bug 903387: slave has rows
ok 27 - Bug 903387: rows deleted on master
ok 28 - Bug 903387: slave still has rows

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PT-910

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.