Results 1 to 10 of 10

Thread: ZRM 2.2 released

  1. #1

    Default ZRM 2.2 released

    ZRM 2.2 includes bug fixes and following features:
    • Support for pre-restore and post-restore plugins
    • Support for mixed replication mode binary logs
    • Support for producing html output after parsing binary logs
    • Support for mail notification policy
    • Added support for exclude pattern for databases and tables in the backup set

    Documentation/Man pages are available at
    [url]http://wiki.zmanda.com/index.php/MySQL_Backup_and_Recovery[/url]

    Images can be downloaded from [url]http://www.zmanda.com/download-zrm.php[/url]

  2. #2

    Default

    Have a few problems with 2.2

    If I run the following command:

    mysql-zrm-reporter --destination /data2/backup --latest --fields innodb_logs,innodb_data

    It shows:

    backup_set innodb_logs innodb_data
    ----------------------------------------------------------------
    set1 ---- ----

    Of course, in the tar file itself, is in fact the innodb data and log files.

    Could the report be this way because the backup is compressed?

    Or, perhaps it's because we use innodb_file_per_table = 1?

    Or, some other reason?

    I unzipped the backup, and, did a tar tvf, and, the innodb files were there with the standard names.

    Secondly, I don't believe the times to be accurate in the reports. compressed_encrypt_time was reported as 12 minutes, when in fact, it took over an hour (monitored with top, bzip2 used 100% cpu, tar used < 1%). So, I suspect it is counting that as backup (tar) time, not, bzip2 time. Without bzip, the backup would have completed almost an hour sooner, so, 12 minutes is not correct. This is a snapshot backup via copy socket of remote server, so, perhaps the correct time is not really possible.

    But it is still strange. backup_time was 01:47:37, which I know is 1 hour+, compress_encrypt_time was 12:39:00, is that 12 hours? If so, obviously, it can't take longer than the backup!

    From the log file:

    Sat Feb 06 16:31:45 2010: shivafull:backup:INFO: PHASE START: Compression/Encryption
    Sat Feb 06 17:47:20 2010: shivafull:backup:INFO: compress=/usr/bin/bzip2
    Sat Feb 06 17:47:20 2010: shivafull:backup:INFO: backup-size-compressed=1.85 GB
    Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: PHASE END: Compression/Encryption
    Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: read-locks-time=00:00:01
    Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: flush-logs-time=00:00:00
    Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: compress-encrypt-time=12:39:00
    Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: backup-time=01:47:37
    Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: backup-status=Backup succeeded
    Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: Backup succeeded

  3. #3

    Default

    1. mysql-zrm-reporter command gets data from the index files. Can you please check the ///index has these entries?

    2. compress_encrypt_time does include the "tar" time. ZRM does creates tar archive of all files and sends out the output to compress and encrypt programs if specified. So, compress and encrypt programs are running for this time.

    3. 12:39:00 appears to be a bug. Can you please set "verbose=1" and attach /var/log/mysql-zrm/mysql-zrm.log?

    thanks,
    Paddy

  4. #4

    Default

    Ok, attached the verbose log from the incremental today. Obviously, the compress time is way off!

    In the index file for the report which did not show innodb_logs, or innodb_data, is:

    innodb-data=/var/lib/mysql/ibdata1;
    innodb-logs=/var/lib/mysql/./ib_logfile*

    Your syntax requires the underscore, but, it had a - in the file. Could that be it?

    If I wanted to use the backup to start MySQL replication by restoring on another machine, this line is in the index:

    next-binlog=binlog.000044

    Would I use that in the change master to command?
    Attached Files Attached Files

  5. #5

    Default

    Thanks for the logs. We will get back to you.

    Please try with "-". The parameter should match the index file contents.

    next-binlog can be used for change master.

    Paddy

  6. #6

    Default

    I cannot use - instead of _ as it then gives a syntax error, and, the help text comes up, and, the help text shows underscore! So, I think the mysql-zrm-reporter command has an error in it as it wants you to type underscore, yet, the data is a dash.

    If next-binlog can be used for change master to, then, what position? I don't see it in the file.

  7. #7

    Default

    You can install it in MacBook provided you have perl. To backup MySQL servers running
    on Mac, backup from another Linux machine.

  8. #8
    Join Date
    Jun 2011
    Posts
    10

    Default

    @ the website, i found the chart showing the diffs bet community and enterprise ZRM.

    what's not clear is, which versions does that refer to? community 2.2.x i guess, but enterprise 2.2.x or 3.3.x?

    other way of asking, what does the version# disparity between current community & enterprise represent? something real? or just numbering randomness?

  9. #9

    Default

    Community 2.2 and Enterprise 3.3. The version numbers between community and enterprise do not match and represents real differences.

  10. #10
    Join Date
    Jun 2011
    Posts
    10

    Default

    is there, then, a Community 3.3 in the works?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •