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  Edit
Everyone can see this information.

Other bug subscribers