Mysql scheme change & replication

schema changes usually lock the corresponding tables. some migrations can work by making the app capable to use both schemas, and multiple db backends so you'd maintain some degree of a working app (read-only) by using your slave for reading while the change is performed on the master.

if you're not crafting a migration just do not bother. if you do, you'd need to expose your specific case rather than rely on some kind of generic statement.

A table that needs to be split into 3 different tables based on date to make one active and 2 archived tables.

ok : there is no actual schema change involved and these operations can be performed while the server is running with zero downtime.

assuming the date column in indexed, you can either do these operations at once or if you have lots of data move the lines let's say 1000 by 1000 ( possibly with a small sleep in between )  and delete them from the original table as you go. this should not put too much of a strain on the db server and keep it responsive.

if you often perform such tasks and use innodb, you may want to look at partitioning as well in order to handle future data : you can have a partition per week for example. both archives and non archives can be queried but mysql will load less data in memory if you only access recent data. additionally partitions can be erased instantly when you need to cleanup.

that database has 6 read only slaves and 3 Co masters ..
what is best to do that effort:
1-Do it on Master?
2-one of the Co masters ?
3-Is it possible to do it on the read only slaves ?