GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

Percona server upgrade and replication

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Percona server upgrade and replication

    Hi!
    I'm using percona mysql server 5.6 with master/slave replication and GTID mode enabled.
    I've had some problems when upgrading percona server on debian: from 5.6.15 to 5.6.16 and from 5.6.16 build 0 to 5.6.16 build 1. I was able to reproduce it several times.
    I was using apt-get upgrade. As far as I understand the sequence is:
    1. Stop the server
    2. Update binaries
    3. ?Run mysql_install_db (and/or some other script) to create new/missing system tables?
    4. Start the server as normal. debian-start notices the binaries upgrade and runs mysql_upgrade in the background.

    So, I have encountered 2 problems
    - During stage (3) updates are written to binlog (e.g. for mysql 'create table user ... if not exists', etc, as statements). I don't want them to be stored, especially because I'm always upgrading the slave server.
    (I've also noticed they are written without GTIDs: "[Warning] Bootstrap mode disables GTIDs. Bootstrap mode should only be used by mysql_install_db which initializes the MySQL data directory and creates system tables." in the log)
    Is there any way to disable binary logging at this stage?
    - After server starts normally GTID mode is enabled again but last binary log rotated has no 'Previous_gtids' event in the begining of the log. It means that next time I restart the server I get the error about logical corruption of this binlog file (when mysql is scanning all the binary log files) and server fails to start:
    "The first global transaction identifier was read, but no other information regarding identifiers existing on the previous log files was found.".

    The only way I found to fix these problems is to FLUSH LOGS (to create a new binlog file with correct headers) and purge all binary logs prior to the new file created.
    Is it a known bug?

    Thanks!

  • #2
    Well, I found that it's a known issue: http://bugs.mysql.com/bug.php?id=71037 (check my comment at the bottom)

    Comment


    • #3
      Hi, Thanks for update.

      Comment

      Working...
      X