{"id":7643,"date":"2016-09-28T16:20:54","date_gmt":"2016-09-28T14:20:54","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=7643"},"modified":"2016-09-28T16:20:54","modified_gmt":"2016-09-28T14:20:54","slug":"three-wishes-for-a-new-year-4","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/three-wishes-for-a-new-year-4","title":{"rendered":"Three wishes for a new year"},"content":{"rendered":"

(Almost) another new year by Jewish calendar. What do I wish for the following year?<\/p>\n

    \n
  1. World peace<\/li>\n
  2. Good health to all<\/li>\n
  3. Relaxed GTID constraints<\/li>\n<\/ol>\n

    I’m still not using GTID, and still see operational issues with working with GTID. As a latest example, our new schema migration solution, gh-ost, allows us to test migrations in production, on replicas. The GTID catch? gh-ost<\/code>\u00a0has to write something to the binary log. Thus, it “corrupts” the replica with a bogus GTID entry that will never be met in another server, thus making said replica unsafe to promote. We can work around this, but…<\/p>\n

    I understand the idea and need for the Executed GTID Set<\/code>. It will\u00a0certainly come in handy with multi-writer InnoDB Cluster. However for most use cases GTID poses a burden. The reason is that our topologies are imperfect, and we as humans are imperfect, and operations are most certainly imperfect. We may wish to operate on a replica: test something, by intention or mistake. We may wish to use a subchain as the seed for a new cluster split. We may wish to be able to write to downstream replicas. We may use a 3rd party tool that issues a flush tables with read lock<\/code>\u00a0without disabling sql_log_bin<\/code>. Things just happen.<\/p>\n

    For that, I would like to suggest GTID control levels, such as:<\/p>\n

      \n
    1. Strict<\/em>: same as Oracle’s existing\u00a0implementation. Executed sets, purged sets, whatnot.<\/li>\n
    2. Last executed<\/em>: a mode where the only thing that counts is the last executed GTID value. If I repoint replica,\u00a0all it needs to check is “hey this is my last executed GTID entry, give me the coordinates of yours. And, no, I don’t care about comparing executed and purged sets, I will trust you and keep running from that point on”<\/li>\n
    3. Declarative<\/em>: GTIDs are generated, are visible in each and every binary log entry, but are completely ignored.<\/li>\n<\/ol>\n

      I realize Oracle MySQL GTID is out for some over 3 years now, but I’m sorry – I still have reservations and see\u00a0use cases where I fear it will not serve me right.<\/p>\n

      How about my previous years wishes? World peace and good health never came through, however:<\/p>\n