Provisioning has to be triggered by a command from slave, so my implementation started there. After performing initial checks, command handler starts IO and SQL threads, like during regular replication. I was trying to write separate code for provisioning IO thread. Main benefit would be clean code to start with – no backward compatibility / bug workaround code – old master will not be able to provide provisioning functionality anyway. On the other hand there would be too much duplicate code, and having to do future changes on two different places is not acceptable. I have decided to use regular replication IO thread as Kristian Nielsen suggested before and add special handling where necessary. Now when the IO thread requests binlog dump from master, it sends packet with following structure master position | binlog flags | server id | log name Master needs to receive information, that slaves IO thread is expecting provisioning data along with current binlog. I have created new BINLOG_PROVISIONING_MODE flag, but I believe that the name is incorrect and it doesn’t belong to binlog flags field. My question is, what is better for compatibility, change binlog flags to any flags and use it for sending information about provisioning request to master (as in current implementation) or add another byte to packet after log name containing provisioning mode flag and possibly more flags later. My current implementation progress can be seen at https://github.com/f4rnham/server/commits/MDEV-7502 diff of all commits at once https://github.com/MariaDB/server/compare/10.1...f4rnham:MDEV-7502 There is one more decision I am not sure about. What should result of provisioning on non-empty slave be? For example, slave contains table with same name in same database as master, but with different columns. Should slave detect already existing tables and fail with error, or silently drop everything what could cause conflicts (add optional FORCE part of provisioning start command?). Which one from these solutions should be default? Or maybe there is third one and better. Thanks for comments, Martin