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.
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-
See:
https:/