1. 06 Aug, 2019 2 commits
  2. 26 Jul, 2019 3 commits
  3. 23 Jul, 2019 2 commits
  4. 24 Jun, 2019 3 commits
  5. 21 Jun, 2019 1 commit
  6. 20 Jun, 2019 1 commit
  7. 19 Jun, 2019 1 commit
  8. 05 Jun, 2019 1 commit
  9. 04 Jun, 2019 1 commit
  10. 31 May, 2019 2 commits
  11. 22 May, 2019 1 commit
  12. 16 May, 2019 1 commit
  13. 25 Apr, 2019 1 commit
  14. 17 Apr, 2019 1 commit
  15. 10 Apr, 2019 1 commit
  16. 09 Apr, 2019 1 commit
  17. 02 Apr, 2019 1 commit
  18. 27 Mar, 2019 4 commits
  19. 12 Mar, 2019 2 commits
  20. 01 Mar, 2019 2 commits
  21. 15 Feb, 2019 1 commit
  22. 21 Jan, 2019 1 commit
  23. 11 Jan, 2019 1 commit
  24. 02 Jan, 2019 2 commits
  25. 27 Dec, 2018 1 commit
    • stack/erp5: Replicate based on slave_pos, not current_pos · 58caaffc
      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.
      Vincent Pelletier committed
  26. 24 Dec, 2018 1 commit
  27. 17 Dec, 2018 1 commit