pt-table-sync checks changing binlog_format on slaves and exists if that does not work. (RDS)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Toolkit moved to https://jira.percona.com/projects/PT |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
pt-table-sync connects to all machines and changes the binlog_
This breaks pt-table-sync to work with RDS.
In the example below, checksumming is being done between a regular database system replicating to a RDS system.
No slaves are attached to the RDS slave.
Then it should be possible for pt-table-sync to work successfully, as long as the master binlog_format can become STATEMENT (which is the case in this example)
This might need a new advanced option to disable this check.
pt-table-sync error (PTDEBUG=1)
# pt_table_sync:10819 12841 DBI::db=
# pt_table_sync:10821 12841 Original binlog_format: MIXED
# pt_table_sync:10825 12841 DBI::db=
Failed to /*!50108 SET @@binlog_format := 'STATEMENT'*/: DBD::mysql::db do failed: Access denied; you need (at least one of) the SUPER privilege(s) for this operation [for Statement "/*!50108 SET @@binlog_format := 'STATEMENT'*/"] at /usr/local/
This tool requires binlog_
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle ;host=*
Changed in percona-toolkit: | |
status: | New → Confirmed |
Hi Kenny, check-binlog- format" option, but in the case of pt-table-sync it's a little less trivial because it actually changes data.
pt-table-checksum has the "--[no]
Although if the user knows what he's doing, this option would solve the problem. Maybe with an added warning, just in case.