# pt-online-schema-change breaks slave replication **URL:** \ **Category:** Other MySQL® Questions\ **Tags:** troubleshooting, mysql\ **Created:** [August 18, 2020, 7:05pm UTC](https://forums.percona.com/t/pt-online-schema-change-breaks-slave-replication/7927 "2020-08-18T19:05:42Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![aluthens](https://avatars.discourse-cdn.com/v4/letter/a/8797f3/32.png) [@aluthens](https://forums.percona.com/u/aluthens)\ **Post date:** [August 18, 2020, 7:05pm UTC](https://forums.percona.com/t/pt-online-schema-change-breaks-slave-replication/7927/1 "2020-08-18T19:05:42Z")
Our database configuration is very simple with one master database and one slave database. Whenever a pt-online-schema-change of any kind (seemingly independent of table size or table alteration being performed), replication ALWAYS breaks on our slave instance. The most recent pt-online-schema-change to break replication was:  ```auto pt-online-schema-change --alter "ADD COLUMN <column>;” --critical-load="Threads_running=100" --no-check-unique-key-change --alter-foreign-keys-method=drop_swap --recursion-method=none --execute D=<db>,t=<t>,u=<u>,p=<p>,h=<host> ``` Almost all of our pt-osc queries are constructed with these flag settings, which must create this problem (or additional flags need to be used to mitigate it). Please let me know if there is anything obvious in why this would cause slave replication to break. Any help is greatly appreciated. Thank you. ---
**Author:** ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)\ **Post date:** [August 22, 2020, 6:44am UTC](https://forums.percona.com/t/pt-online-schema-change-breaks-slave-replication/7927/2 "2020-08-22T06:44:21Z")
It would be best if you can provide us with the table structure (SHOW CREATE TABLE tblname\G) and the SHOW SLAVE STATUS\G output with the error. ---
**Author:** ![aluthens](https://avatars.discourse-cdn.com/v4/letter/a/8797f3/32.png) [@aluthens](https://forums.percona.com/u/aluthens)\ **Post date:** [August 24, 2020, 9:48am UTC](https://forums.percona.com/t/pt-online-schema-change-breaks-slave-replication/7927/3 "2020-08-24T09:48:58Z")
It has nothing to do with the table structure, as replication instantly breaks with the same exception no matter what table is being modified or how it is being altered. The exception is as follows:  ```auto Altering `<db>`.`<table>`... Creating new table... Created new table <db>._<table>_new OK. Altering new table... Altered `<db>`.`_<table>_new` OK. 2020-08-21T21:00:00 Creating triggers... 2020-08-21T21:00:00 Created triggers OK. 2020-08-21T21:00:00 Copying approximately 6162 rows... (2) Replica h=<host>,P=<port> is stopped. Waiting. (1) Replica h=<host>,P=<port> is stopped. Waiting. (1) Replica h=<host>,P=<port> is stopped. Waiting. (1) Replica h=<host>,P=<port> is stopped. Waiting. (1) Replica h=<host>,P=<port> is stopped. Waiting. (1) Replica h=<host>,P=<port> is stopped. Waiting. (1) Replica h=<host>,P=<port> is stopped. Waiting. ^C# Exiting on SIGINT.
``` As you can see, replication breaks presumably right after creating triggers or once it tries to start copying data. Once it breaks, it is seemingly in an infinite loop in which the patch will never finish. This has happened on countless tables all of different structures and alter operations, so it is absolutely not anything to do with the table structure, but rather a MySQL database configuration or replica configuration. ---
**Author:** ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)\ **Post date:** [September 5, 2020, 4:53am UTC](https://forums.percona.com/t/pt-online-schema-change-breaks-slave-replication/7927/4 "2020-09-05T04:53:42Z")
Unfortunately, with the amount of information we have it would be difficult to reproduce this. Can you provide output of SHOW SLAVE STATUS\G, and config file for both source and replica? ---
**Author:** ![aluthens](https://avatars.discourse-cdn.com/v4/letter/a/8797f3/32.png) [@aluthens](https://forums.percona.com/u/aluthens)\ **Post date:** [September 7, 2020, 4:40pm UTC](https://forums.percona.com/t/pt-online-schema-change-breaks-slave-replication/7927/5 "2020-09-07T16:40:44Z")
Thank you, but I have since solved the problem. This appeared to have occurred because the binlog\_format was set to _‘STATEMENT’_. After switching it to _‘MIXED’_ our problems were resolved.