1

the first step is to checksum difference and record into percona.checksum table

pt-table-checksum h=xx,P=xx,u=xx,p=xx method=dsn=h=xx,D=xx,t=xx --databases=kobe

the second step is to print the repair SQL into a file

pt-table-sync --print --sync-to-master h=xx,P=xx,u=xx,p=xx >repair.sql

and I need to take this repairsql file to developers,show them how many records are difference, difference detail, and let them make sure。Ater that I execute the repair sql

so my question is what I execute this old repair SQL, the new data is inserting ,and the new difference is creating, maybe this old repair SQL will cover the latest data !

can anybody help me ? thank you !

0

Use the --where option

Do only rows matching this WHERE clause. You can use this option to limit the checksum to only part of the table. This is particularly useful if you have append-only tables and don’t want to constantly re-check all rows; you could run a daily job to just check yesterday’s rows, for instance.

This option is much like the -w option to mysqldump. Do not specify the WHERE keyword. You might need to quote the value. Here is an example:

pt-table-checksum --where "ts > CURRENT_DATE - INTERVAL 1 DAY"

Source: https://www.percona.com/doc/percona-toolkit/2.2/pt-table-checksum.html#cmdoption-pt-table-checksum--where

0

The problem with this technique is that the database is still live, making it a moving target.

The SQL generated from the [--print][1] option against a live DB Server is more for giving you a preview of the SQL you are about to execute than for using the SQL script.

Since there are live writes going on, you must decide between the following two approaches to go with:

APPROACH #1 : SHOOT FIRST AND ASK QUESTIONS LATER

If you choose to perform your repair with the application up, here are your steps

  • Execute pt-table-sync with --print to repair.sql
  • Review repair.sql and certify that the changes are what you expect
  • Check your blood pressure; Have your meds on standby
  • Execute pt-table-sync with --execute option
  • Execute pt-table-sync with --print to repair_after.sql

APPROACH #2 : APPLICATION DOWNTIME

  • Execute pt-table-sync with --print to repair.sql
  • Review repair.sql and certify that the changes are what you expect
  • Check your blood pressure; Have your meds on standby
  • Stop application
  • Execute pt-table-sync with --execute option
  • Execute pt-table-sync with --print to repair_after.sql
  • Compare repair.sql with repair_after.sql
  • Start application

EPILOGUE

For APPROACH #2, repair_after.sql should be empty if all goes well.

For APPROACH #1, you would have to repeat your steps until repair_after.sql is as close to empty as possible.

You should test these approaches on a Staging Server.

You should always make a backup of the database.

GIVE IT A TRY !!!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.