Commit 58caaffc by Vincent Pelletier

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.
parent e44932b0
......@@ -22,7 +22,7 @@ md5sum = 0c0d98a68230cd0ad36046bb25b35f4a
[mariadb-start-clone-from-backup]
filename = instance-mariadb-start-clone-from-backup.sh.in
md5sum = e405227118a70fbf949a6414469989db
md5sum = d95e8500bdc72d1f40b97cc414656e7e
[template-mariadb]
filename = instance-mariadb.cfg.in
......
......@@ -89,7 +89,7 @@ zcat "$BACKUP" | "$CLIENT" -u root
echo "Configuring server as slave..."
if [ "$MASTER_USE_GTID" -eq 1 ]; then
"$CLIENT" -u root -e "$SQL_SET_GTID"
MASTER_USE_GTID_SQL="current_pos"
MASTER_USE_GTID_SQL="slave_pos"
else
MASTER_USE_GTID_SQL="NO"
fi
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or sign in to comment