stack/erp5: Replicate based on slave_pos, not current_pos
The query present in the sql dump sets gtid_slave_pos, which is used by slave_pos. current_pos relies on gtid_current_pos, which is not set here and hence fails to initiate replication. Another (unintended) effect of using slave_pos is that queries run on the slave will not break replication. There should be no reason to run queries on slave (at least, data & schema modification queries while replication is active), so it would seem better to fail the replication immediately in order to detect this. So this may not be the best solution - but at least this fixes this script.
Showing with 2 additions and 2 deletions