1. 14 Jan, 2019 9 commits
  2. 11 Jan, 2019 1 commit
    • Marko Mäkelä's avatar
      Remove code duplication around buf_pool->flush_rbt · e7924a85
      Marko Mäkelä authored
      The purpose of buf_pool->flush_rbt is to ensure that
      buf_pool->flush_list is ordered by oldest_modification.
      This should speed up multi-pass redo log application
      (when the buffer pool is not large enough to accommodate
      all pages that were modified since the latest log checkpoint).
      
      The buf_pool->flush_rbt is not being used after redo log has
      been applied. It could be better to always flush pages in
      the ascending order of oldest_modification. Currently, whenever
      a page is first modified, it will be moved to the start of the
      buf_pool->flush_list, overtaking blocks whose oldest_modification
      could be much older.
      
      buf_flush_insert_sorted_into_flush_list(): Merge into
      buf_flush_insert_into_flush_list().
      
      buf_flush_recv_note_modification(): Remove.
      The function buf_flush_note_modification() can be invoked instead.
      e7924a85
  3. 10 Jan, 2019 2 commits
  4. 09 Jan, 2019 5 commits
  5. 08 Jan, 2019 5 commits
  6. 07 Jan, 2019 5 commits
  7. 06 Jan, 2019 2 commits
  8. 04 Jan, 2019 7 commits
  9. 03 Jan, 2019 4 commits
    • Marko Mäkelä's avatar
      Fix a merge error in the parent commit · 23e4446a
      Marko Mäkelä authored
      Fix an inadvertently inverted condition that caused
      galera.galera_sst_mariabackup_table_options test failure.
      23e4446a
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 94e22efb
      Marko Mäkelä authored
      94e22efb
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · b7392d14
      Marko Mäkelä authored
      b7392d14
    • Marko Mäkelä's avatar
      MDEV-18129 Backup fails for encrypted tables: mariabackup: Database page... · 7158edcb
      Marko Mäkelä authored
      MDEV-18129 Backup fails for encrypted tables: mariabackup: Database page corruption detected at page 1
      
      If an encrypted table is created during backup, then
      mariabackup --backup could wrongly fail.
      
      This caused a failure of the test mariabackup.huge_lsn once on buildbot.
      
      This is due to the way how InnoDB creates .ibd files. It would first
      write a dummy page 0 with no encryption information. Due to this,
      xb_fil_cur_open() could wrongly interpret that the table is not encrypted.
      Subsequently, page_is_corrupted() would compare the computed page
      checksum to the wrong checksum. (There are both "before" and "after"
      checksums for encrypted pages.)
      
      To work around this problem, we introduce a Boolean option
      --backup-encrypted that is enabled by default. With this option,
      Mariabackup will assume that a nonzero key_version implies that the
      page is encrypted. We need this option in order to be able to copy
      encrypted tables from MariaDB 10.1 or 10.2, because unencrypted pages
      that were originally created before MySQL 5.1.48 could contain nonzero
      garbage in the fields that were repurposed for encryption.
      
      Later, MDEV-18128 would clean up the way how .ibd files are created,
      to remove the need for this option.
      
      page_is_corrupted(): Add missing const qualifiers, and do not check
      space->crypt_data unless --skip-backup-encrypted has been specified.
      
      xb_fil_cur_read(): After a failed page read, output a page dump.
      7158edcb