pt-online-schema-change will proceed even if no slaves are connectable, rendering throttling useless

Bug #1092344 reported by rcoli on 2012-12-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Toolkit moved to

Bug Description

1) run pt-osc with a user who has permissions to the master but not the slaves
2) notice many errors like : print STDERR "Cannot connect to ", $dp->as_string($dsn), "\n"
3) even if 100% of slaves fail, pt-online-schema-change proceeds with the ALTER, but is unable to monitor any slave lag. this would appear to render any lag-based throttling irrelevant
4) users typically expect throttling to work when it is enabled by default

I suggest making it FATAL when you can discover slaves but are unable to monitor a single one, and require that the user set --recursion-method=none if they want this behavior. Many people might have a good reason to ignore one of a list of slaves, but I think it is more rare for someone to want to ignore ALL of them.

tags: added: privs pt-online-schema-change
Changed in percona-toolkit:
status: New → Triaged
Frank Cizmich (frank-cizmich) wrote :

This is an oldie, so some things have changed back and forth since.
Current behavior (v2.2.15) is to not exit when a slave is unreachable. This is desirable when you have a very long run (hours/days) with various slaves and at some point you want to take one offline (for whatever reason), but don't want tool to exit and lose all the work done.
I think the situation described in the report can be handled with --recursion-method=dsn , where you can tell the tool exactly which slaves to monitor, (using different user/passwords if necessary)


Changed in percona-toolkit:
status: Triaged → Invalid

Percona now uses JIRA for bug reports so this bug report is migrated to:

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

Other bug subscribers