Skip to content


Создание бекапа mysql-сервера с помощью Percona xtrabackup

логотип mysql

Создание бекапа mysql-базы без остановки сервера

Для очень больших баз данных MySQL использование традиционных средств создания бекапов, таких как mysqldump, сопряжено с рядом трудностей:

1. По умолчанию таблицы лочатся на запись --- на время создания бекапа нельзя писать в базу. Для mission-critical приложений это неприемлимо. Однако, в случае таблиц InnoDB это ограничение можно обойти с помощью ключа mysqldump --single-transaction.

2. Создание дампа и восстановление из него занимает очень много времени. Так, для одной из баз, с которой мне приходилось сталкиваться, дамп размером 50ГБ создавался 5 часов (и это на совсем не слабом сервере - 256ГБ RAM, четыре 6-ти-ядерных CPU Xeon E7540 2.0GHz c HT). Вливание этого дампа назад в базу заняло бы примерно столько же времени.

Percona xtrabackup позволяет буквально двумя командами получить рабочую копию базы без какого-либо прерывания работы MySQL-сервера, причём намного быстрее, чем mysqldump. Пример:

  1. # rpm -ivh xtrabackup-1.6-245.rhel5.x86_64.rpm
  2. [admin@master] $ innobackupex /backups
  3.  
  4. InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
  5. and Percona Inc 2009-2011.  All Rights Reserved.
  6.  
  7. This software is published under
  8. the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
  9.  
  10. 110623 11:59:51  innobackupex: Starting mysql with options:  --unbuffered --
  11. 110623 11:59:51  innobackupex: Connected to database with mysql child process (pid=3685)
  12. 110623 11:59:57  innobackupex: Connection to database server closed
  13. IMPORTANT: Please check that the backup run completes successfully.
  14.            At the end of a successful backup run innobackupex
  15.            prints "completed OK!".
  16.  
  17. innobackupex: Using mysql  Ver 14.14 Distrib 5.5.13, for Linux (x86_64) using readline 5.1
  18. innobackupex: Using mysql server version Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
  19.  
  20. innobackupex: Created backup directory /backups/2011-06-23_11-59-57
  21. 110623 11:59:57  innobackupex: Starting mysql with options:  --unbuffered --
  22. 110623 11:59:57  innobackupex: Connected to database with mysql child process (pid=3712)
  23. 110623 12:00:01  innobackupex: Connection to database server closed
  24.  
  25. 110623 12:00:01  innobackupex: Starting ibbackup with command: xtrabackup_55 --backup --suspend-at-end --target-dir=/backups/2011-06-23_11-59-57
  26. innobackupex: Waiting for ibbackup (pid=3724) to suspend
  27. innobackupex: Suspend file '/backups/2011-06-23_11-59-57/xtrabackup_suspended'
  28.  
  29. xtrabackup_55  Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
  30. xtrabackup: uses posix_fadvise().
  31. xtrabackup: cd to /var/lib/mysql
  32. xtrabackup: Target instance is assumed as followings.
  33. xtrabackup:   innodb_data_home_dir = ./
  34. xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
  35. xtrabackup:   innodb_log_group_home_dir = ./
  36. xtrabackup:   innodb_log_files_in_group = 2
  37. xtrabackup:   innodb_log_file_size = 5242880
  38. 110623 12:00:01 InnoDB: Using Linux native AIO
  39. >> log scanned up to (15576575786)
  40. [01] Copying ./ibdata1
  41.      to /backups/2011-06-23_11-59-57/ibdata1
  42. >> log scanned up to (15576821168)
  43. >> log scanned up to (15576993781)
  44. >> log scanned up to (15577223204)
  45. >> log scanned up to (15577401335)
  46. >> log scanned up to (15577646737)
  47. >> log scanned up to (15577864382)
  48. >> log scanned up to (15578032411)
  49. >> log scanned up to (15578302721)
  50. >> log scanned up to (15578496370)
  51. >> log scanned up to (15578695368)
  52. >> log scanned up to (15578966232)
  53. >> log scanned up to (15579121683)
  54. >> log scanned up to (15579340135)
  55. >> log scanned up to (15579572684)
  56. >> log scanned up to (15579801008)
  57. >> log scanned up to (15579918009)
  58. >> log scanned up to (15580129220)
  59. >> log scanned up to (15580377234)
  60. >> log scanned up to (15580543590)
  61. >> log scanned up to (15580811908)
  62. >> log scanned up to (15580992609)
  63. >> log scanned up to (15581162267)
  64. >> log scanned up to (15581314789)
  65. >> log scanned up to (15581469774)
  66. >> log scanned up to (15581662444)
  67. >> log scanned up to (15581858152)
  68. >> log scanned up to (15582046357)
  69. >> log scanned up to (15583450833)
  70. >> log scanned up to (15584545328)
  71. >> log scanned up to (15584847700)
  72. >> log scanned up to (15585508334)
  73. >> log scanned up to (15587171262)
  74. >> log scanned up to (15588573028)
  75. [01]        ...done
  76.  
  77. 110623 12:03:15  innobackupex: Continuing after ibbackup has suspended
  78. 110623 12:03:15  innobackupex: Starting mysql with options:  --unbuffered --
  79. 110623 12:03:15  innobackupex: Connected to database with mysql child process (pid=4879)
  80. >> log scanned up to (15591908670)
  81. 110623 12:03:19  innobackupex: Starting to lock all tables...
  82. >> log scanned up to (15597590433)
  83. >> log scanned up to (15598452337)
  84. 110623 12:03:29  innobackupex: All tables locked and flushed to disk
  85.  
  86. 110623 12:03:29  innobackupex: Starting to backup .frm, .MRG, .MYD, .MYI,
  87. innobackupex: .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV and .opt files in
  88. innobackupex: subdirectories of '/var/lib/mysql'
  89. innobackupex: Backing up files '/var/lib/mysql/mysql/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (72 files)
  90. innobackupex: Backing up files '/var/lib/mysql/performance_schema/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (18 files)
  91. innobackupex: Backing up files '/var/lib/mysql/salesdb/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (210 files)
  92. >> log scanned up to (15598452487)
  93. >> log scanned up to (15598452783)
  94. 110623 12:03:43  innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt files
  95.  
  96. innobackupex: Resuming ibbackup
  97.  
  98. >> log scanned up to (15598452993)
  99. xtrabackup: The latest check point (for incremental): '15594901984'
  100. >> log scanned up to (15598452993)
  101. xtrabackup: Stopping log copying thread.
  102. xtrabackup: Transaction log of lsn (15574068024) to (15598452993) was copied.
  103. 110623 12:03:46  innobackupex: All tables unlocked
  104. 110623 12:03:46  innobackupex: Connection to database server closed
  105.  
  106. innobackupex: Backup created in directory '/backups/2011-06-23_11-59-57'
  107. innobackupex: MySQL binlog position: filename 'mysql-bin.000009', position 537035213            mysql
  108. 110623 12:03:46  innobackupex: completed OK!

Далее "приготавливаем" бекап путем обработки лога транзакций, который на этом этапе хранится в файле xtrabackup_logfile.

  1. [admin@master] $ innobackupex --apply-log /backups/2011-06-23_11-59-57/
  2.  
  3. InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
  4. and Percona Inc 2009-2011.  All Rights Reserved.
  5.  
  6. This software is published under
  7. the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
  8.  
  9. IMPORTANT: Please check that the apply-log run completes successfully.
  10.            At the end of a successful apply-log run innobackupex
  11.            prints "completed OK!".
  12.  
  13. 110623 12:31:28  innobackupex: Starting ibbackup with command: xtrabackup_55
  14. --prepare --target-dir=/backups/2011-06-23_11-59-57
  15.  
  16. xtrabackup_55  Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
  17. xtrabackup: cd to /backups/2011-06-23_11-59-57
  18. xtrabackup: This target seems to be not prepared yet.
  19. xtrabackup: xtrabackup_logfile detected: size=27443200,start_lsn=(15574068024)
  20. xtrabackup: Temporary instance for recovery is set as followings.
  21. xtrabackup:   innodb_data_home_dir = ./
  22. xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
  23. xtrabackup:   innodb_log_group_home_dir = ./
  24. xtrabackup:   innodb_log_files_in_group = 1
  25. xtrabackup:   innodb_log_file_size = 27443200
  26. 110623 12:31:28 InnoDB: Using Linux native AIO
  27. xtrabackup: Starting InnoDB instance for recovery.
  28. xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter
  29. 110623 12:31:28 InnoDB: The InnoDB memory heap is disabled
  30. 110623 12:31:28 InnoDB: Mutexes and rw_locks use GCC atomic builtins
  31. 110623 12:31:28 InnoDB: Compressed tables use zlib 1.2.3
  32. 110623 12:31:28 InnoDB: Using Linux native AIO
  33. 110623 12:31:28 InnoDB: Warning: innodb_file_io_threads is deprecated. Please
  34. use innodb_read_io_threads and innodb_write_io_threads instead
  35. 110623 12:31:28 InnoDB: Initializing buffer pool, size = 100.0M
  36. 110623 12:31:28 InnoDB: Completed initialization of buffer pool
  37. 110623 12:31:28 InnoDB: highest supported file format is Barracuda.
  38. InnoDB: Log scan progressed past the checkpoint lsn 15574068024
  39. 110623 12:31:28  InnoDB: Database was not shut down normally!
  40. InnoDB: Starting crash recovery.
  41. InnoDB: Reading tablespace information from the .ibd files...
  42. InnoDB: Doing recovery: scanned up to log sequence number 15579310592 (21 %)
  43. InnoDB: Doing recovery: scanned up to log sequence number 15584553472 (42 %)
  44. InnoDB: Doing recovery: scanned up to log sequence number 15589796352 (64 %)
  45. InnoDB: Doing recovery: scanned up to log sequence number 15595039232 (85 %)
  46. 110623 12:31:29  InnoDB: Starting an apply batch of log records to the
  47. database...
  48. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
  49. 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
  50. 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
  51. 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
  52. 97 98 99
  53. InnoDB: Apply batch completed
  54. InnoDB: Doing recovery: scanned up to log sequence number 15598452993 (99 %)
  55. 110623 12:31:38  InnoDB: Starting an apply batch of log records to the
  56. database...
  57. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
  58. 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
  59. 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
  60. 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
  61. 97 98 99
  62. InnoDB: Apply batch completed
  63. InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
  64. 110623 12:31:39  InnoDB: Waiting for the background threads to start
  65. 110623 12:31:40 Percona XtraDB (http://www.percona.com) 1.1.5-20.0 started;
  66. log sequence number 15598452993
  67.  
  68. [notice (again)]
  69.   If you use binary log and don't use any hack of group commit,
  70.  the binary log position seems to be:
  71. InnoDB: Last MySQL binlog file position 0 537035213, file name
  72. ./mysql-bin.000009
  73.  
  74. xtrabackup: starting shutdown with innodb_fast_shutdown = 1
  75. 110623 12:31:40  InnoDB: Starting shutdown...
  76. 110623 12:31:44  InnoDB: Shutdown completed; log sequence number 15598454344
  77.  
  78. 110623 12:31:44  innobackupex: Restarting xtrabackup with command:
  79. xtrabackup_55 --prepare --target-dir=/backups/2011-06-23_11-59-57
  80. for creating ib_logfile*
  81.  
  82. xtrabackup_55  Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
  83. xtrabackup: cd to /backups/2011-06-23_11-59-57
  84. xtrabackup: This target seems to be already prepared.
  85. xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
  86. xtrabackup: Temporary instance for recovery is set as followings.
  87. xtrabackup:   innodb_data_home_dir = ./
  88. xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
  89. xtrabackup:   innodb_log_group_home_dir = ./
  90. xtrabackup:   innodb_log_files_in_group = 2
  91. xtrabackup:   innodb_log_file_size = 5242880
  92. 110623 12:31:44 InnoDB: Using Linux native AIO
  93. xtrabackup: Starting InnoDB instance for recovery.
  94. xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory
  95. parameter)
  96. 110623 12:31:44 InnoDB: The InnoDB memory heap is disabled
  97. 110623 12:31:44 InnoDB: Mutexes and rw_locks use GCC atomic builtins
  98. 110623 12:31:44 InnoDB: Compressed tables use zlib 1.2.3
  99. 110623 12:31:44 InnoDB: Using Linux native AIO
  100. 110623 12:31:44 InnoDB: Warning: innodb_file_io_threads is deprecated. Please
  101. use innodb_read_io_threads and innodb_write_io_threads instead
  102. 110623 12:31:44 InnoDB: Initializing buffer pool, size = 100.0M
  103. 110623 12:31:44 InnoDB: Completed initialization of buffer pool
  104. 110623 12:31:44  InnoDB: Log file ./ib_logfile0 did not exist: new to be
  105. created
  106. InnoDB: Setting log file ./ib_logfile0 size to 5 MB
  107. InnoDB: Database physically writes the file full: wait...
  108. 110623 12:31:45  InnoDB: Log file ./ib_logfile1 did not exist: new to be
  109. created
  110. InnoDB: Setting log file ./ib_logfile1 size to 5 MB
  111. InnoDB: Database physically writes the file full: wait...
  112. 110623 12:31:46 InnoDB: highest supported file format is Barracuda.
  113. InnoDB: The log sequence number in ibdata files does not match
  114. InnoDB: the log sequence number in the ib_logfiles!
  115. 110623 12:31:46  InnoDB: Database was not shut down normally!
  116. InnoDB: Starting crash recovery.
  117. InnoDB: Reading tablespace information from the .ibd files...
  118. InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
  119. 110623 12:31:46  InnoDB: Waiting for the background threads to start
  120. 110623 12:31:47 Percona XtraDB (http://www.percona.com) 1.1.5-20.0 started;
  121. log sequence number 15598454796
  122.  
  123. [notice (again)]
  124.  If you use binary log and don't use any hack of group commit,
  125.   the binary log position seems to be:
  126. InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
  127.  
  128. xtrabackup: starting shutdown with innodb_fast_shutdown = 1
  129. 110623 12:31:47  InnoDB: Starting shutdown...
  130. 110623 12:31:52  InnoDB: Shutdown completed; log sequence number 15598455780
  131. 110623 12:31:52  innobackupex: completed OK!

Скрипт для своей работы требует наличия опции datadir (обычно её значение "/var/lib/mysql") в конфигурационном файле my.cnf. В результате в директории /backups/2011-06-23_11-59-57 появляется полностью рабочая бинарная копия всех баз данных MySQL с данного сервера. В случае необходимости восстановления данных из созданного таким образом бекапа нужно остановить mysqld, скопировать содержимое директории /backups/2011-06-23_11-59-57 в /var/lib/mysql и вновь запустить mysqld.


От простого копирования содержимого директории с данными /var/lib/mysql данный подход отличается тем, что данные копируются особым образом, таким же, как с ними работает движок InnoDB и вместе с данными копируются лог-файлы. На 2-ом этапе подготовки (prepare) xtrabackup запускает встроенный в него слегка модифицированный InnoDB-движок и выполняет crash-recovery, используя информацию из лог-файлов. Этот шаг необходим, поскольку в процессе копирования mysql-сервер продолжает изменять базу и без него была бы нарушена целостность данных.

Пример из практики: база размером 80ГБ (du -sh /var/lib/mysql) первой командой копировалась 36 минут, вторая команда отрабатывала (там где --apply-log) 39 минут. По сети файлы переливались с master-а на slave 43 минуты. Итого на поднятие slave-сервера ушло 118 минут (2 часа). Как видно, в разы быстрее, чем было бы с mysqldump-ом и без какого-либо downtime.

Вот более удобный вариант использования, укоряющий перенос базы c master-а (с IP-адресом 10.11.12.12) на новый сервер, который будет slave-ом (с IP-адресом 10.11.12.13). Пакет xtrabackup должен быть установлен на обоих серверах.

  1. [avz@slave] mkdir /tmp/db
  2. [avz@master] innobackupex --defaults-file=/etc/my2.cnf --socket=/var/lib/mysql2/mysql.sock --remote-host=avz@10.11.12.13 --tmpdir=/tmp /tmp/db
  3. [avz@slave] innobackupex --defaults-file=/etc/my2.cnf --apply-log --ibbackup=xtrabackup_55 /tmp/db/2011-06-23_12-52-23
  4. [root@slave] service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
  5. [root@slave] mv /tmp/db/2011-06-23_12-52-23 /var/lib/mysql
  6. [root@slave] chown -R mysql.mysql /var/lib/mysql
  7. [root@slave] service mysqld start
  1. master> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.11.12.13' IDENTIFIED BY 'SomePassw';
  2. slave> CHANGE MASTER TO MASTER_HOST='10.11.12.12', MASTER_PORT=3307, MASTER_USER='repl', MASTER_PASSWORD='SomePassw', MASTER_LOG_FILE='master-bin.001269', MASTER_LOG_POS=517948556;
  3. slave> START SLAVE;

Команда во второй строке копирует данные и InnoDB-лог-файлы сразу на удалённый slave-сервер с адресом 10.11.12.13 в каталог /tmp/db с помощью scp. Параметры --defaults-file и --socket нужны в том случае, если на master-сервере несколько экземпляров mysqld – с помощью этих параметров явно указываем какой конфиг-файл использовать и к какому именно экземпляру нужно подключаться. Очень желательно настроить SSH-аутентификацию на ключах, чтобы можно было подключаться с master-а на slave без ввода пароля. На slave-сервере каталог /tmp/db должен быть создан предварительно. Команда в третьей строчке, запущенная уже на slave-сервере, выполняет восстановление базы на основе информации из log-файлов.

Параметр --ibbackup необходимо указать в том случае, если на момент запуска этой команды на slave-сервере еще не запущен mysqld. Она указывает какой именно бинарник xtrabackup использовать (в используемой на данной момент версии их три – xtrabackup, xtrabackup_51 и xtrabackup_55). Если же mysql-сервер на slave-сервере был запущен до того, как выполняется команда из строки 3, то версия нужного бинарника обычно определяется автоматически и использовать параметр --ibbackup нужды не возникает. После "innobackupex --apply-log ..." данные приобретают целостность и готовы к работе.

Желательно, чтобы под пользователем, который выполняет innobackupex, подключение к базе происходило без пароля. Иначе возникает необходимость добавить в 1-ую команду параметры --user и --password.

Значения для MASTER_LOG_FILE и MASTER_LOG_POS на 9-м шаге берутся из вывода команд на 2-м или 3-м шаге.

Еще пример из практики: суммарный размер файлов базы: 255ГБ (du -sh /var/lib/mysql), размер заархивированного gzip-ом SQL-дампа – 33ГБ. Первый этап (команда из 2-ой строки) выполнялся 7 часов 10 минут (сюда входит и передача по сети с помощью scp, к которой оба сервера подключены на скорости 1Гбит/сек). Второй этап (команда из 3-ей строки) занял 13 минут. После запуска mysqld на slave-сервере и команд "CHANGE MASTER TO..." + "START SLAVE" оказалось, что slave отстаёт от master-а примерно на пол-часа. Это отставание slave нагнал примерно за 7 минут. ИТОГО: весь процесс построения реплики со старта до получения рабочего slave-сервера с идентичными master-у данными занял 7 часов 30 минут. Конфигурация серверов в этом примере: 4 x Intel Xeon E7540 @2.00GHz (процессор 6-ти ядерный, в /proc/cpuinfo видно 48 ядер), RAM 256ГБ, диски 4x500ГБ SSD в RAID-10.

UPDATE от 04.09.2013.

В версии 2.1.4 уже всё немного поменялось (может и раньше, это просто первая из 2-й ветки, с которой я имел дело). Теперь процедура создания бекапа сразу на другом сервере выглядит так:

  1. [avz@slave] mkdir /tmp/db
  2. [avz@master] innobackupex --defaults-file=/etc/my2.cnf --socket=/var/lib/mysql2/mysql.sock --tmpdir=/tmp /tmp/db --compress --stream=xbstream ./ | ssh avz@slave "cd /tmp/db; xbstream -x"
  3. [avz@slave] for bf in `find /tmp/db -iname "*\.qp"`; do echo "processing $bf" ; qpress -d $bf $(dirname $bf) && rm -f $bf; done
  4. [avz@slave] xtrabackup --prepare --target-dir=/tmp/db
  5. [avz@slave] innobackupex --defaults-file=/etc/my2.cnf --apply-log /tmp/db
  6. [root@slave] # service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
  7. [root@slave] # mv /tmp/db/* /var/lib/mysql
  8. [root@slave] # chown -R mysql.mysql /var/lib/mysql
  9. [root@slave] # service mysqld start

Сетевой трафик - этап 1 (гигабитный интерфейс)

Сетевой трафик - этап 1 (гигабитный интерфейс)


Для базы размером 135ГБ (du -sh /var/lib/mysql) длительность выполнения процедуры была следующей:

  • команда в строке 2 выполнялась 67 минут;
  • команда в строке 3 выполнялась 11 минут 12 секунд;
  • команда в строке 4 выполнялась 1 минуту 10 секунд;
  • команда в строке 5 выполнялась 5 секунд;

Также важно отметить, что сжатие с помощью опции --compress приводит к уменьшению размера ibd-файлов примерно в 2 раза.

Здесь конфигурация железа была следующей.
Master: CPU Intel Xeon E7540 @2.00GHz, RAM 256GB, RAID-10 на 4-x SSD-дисках INTEL SSDSA2CW600G3
Slave: CPU Intel Xeon E5-2650 0 @2.00GHz, RAM 256GB, RAID-10 на 4-x SSD-дисках EDGE Boost Pro

Утилиту qpress и сам xtrabackup удобнее всего брать в официальном репозитории Percona.

Данный инструмент распространяется по принципу open-source и является бесплатным, успешно протестирован мной в реальных условиях и замечательно работает как для простого резервного копирования, так и для копирования данных с целью поднятия slave-сервера для репликации. Поэтому я нахожу Percona xtrabackup весьма ценной штукой, учитывая что сам Oracle софт с аналогичной функциональностью предоставляет за деньги.

UPDATE от 2015-09-10.
Последний раз успешно поднял slave такой последовательностью команд:

  1. [avz@slave] mkdir /tmp/db
  2. [avz@master] innobackupex --defaults-file=/etc/my.cnf --socket=/var/lib/mysql/mysql.sock --tmpdir=/tmp --compress --compress-threads=8 --stream=xbstream --parallel=4 --lock-wait-timeout=120 --password=xxxxxx ./ | ssh avz@slave "xbstream -x -C /tmp/db"
  3. [avz@slave] for bf in `find /tmp/db -iname "*\.qp"`; do echo "processing $bf" ; qpress -d $bf $(dirname $bf) && rm -f $bf; done
  4. [avz@slave] innobackupex --defaults-file=/etc/my.cnf --apply-log --use-memory=190G /tmp/db
  5. [root@slave] # service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
  6. [root@slave] # mv /tmp/db/* /var/lib/mysql
  7. [root@slave] # chown -R mysql.mysql /var/lib/mysql
  8. [root@slave] # service mysqld start

Версия MySQL: 5.6.23. Версия percona-xtrabackup: 2.2.12. Размер базы 240GB (по данным du -sh). Объем памяти на мастере и слейве - 192GB. Процесс занял часа 4. Lock таблиц на мастере продлился чуть более 5-ти минут:

  1. 150907 13:55:32  innobackupex: Executing FLUSH TABLES WITH READ LOCK...
  2. 150907 14:00:50  innobackupex: All tables unlocked

Параметр --lock-wait-timeout=120 означает, что xtrabackup будет ждать удобный момент для "FLUSH TABLES WITH READ LOCK", когда нет выполняющихся длинных запросов. Но ждать такой момент он будет не более 120 секунд. Если за 120 секунд не дождется, то отвалится с ошибкой. Если параметр не указать, то "удобный момент" выбираться не будет. Выдержка из официальной документации:

Waiting for queries to finish. Good moment to issue a global lock is the moment when there are no long queries running. But waiting for a good moment to issue the global lock for extended period of time isn’t always good approach, as it can extend the time needed for backup to take place. To prevent innobackupex from waiting to issue FLUSH TABLES WITH READ LOCK for too long, new option has been implemented: --lock-wait-timeout option can be used to limit the waiting time. If the good moment to issue the lock did not happen during this time, innobackupex will give up and exit with an error message and backup will not be taken. Zero value for this option turns off the feature (which is default).

UPDATE от 2016-07-15.
Если приходится иметь дело с MySQL версии 5.7.x, то нужно использовать пакет percona-xtrabackup-24 (а не percona-xtrabackup как было ранее). Есть все в том же репозитории.

Кстати, если кому надо: Нагревательный кабель для обогрева в Донецке, Одессе tepliypol.com.ua

Интересует meatec.ru - электроэрозионный проволочный станок звоните: +7 495 626-99-87

Размещено в категории *nix, Howto. Теги: , , .

Комментариев: 11

Чтобы быть всегда в курсе здесь происходящего, Вы можете подписаться на RSS feed для комментариев на эту заметку.

  1. Serg said

    Я попробовал использовать этот скрипт, но нарвался на то, что серверу поплохело из-за большого дискового IO. Поэтому рекомендую запускать бекапилку как-то так:

    ionice -c 3 innobackupex --throttle=40 /tmp/mysql-backup

    Да, это медленнее, зато не мешает серверу выполнять его основные задачи.

  2. Попробовал я проделать всё описанное в статье, получилось. Но хочу заметить, что всё-таки какая-то кратковременная блокировка на мастере возникает. У меня на графике хитов (обновляется раз в минуту) для сайта с посещаемостью около сотни хостов в минуту отрисовался заметный провал как раз в то время, когда выполнялась первая стадия xtrabackup-а.

  3. Admin said

    Ага, точно: к конце процесса копирования innodb-таблиц на консоли появляется примерно следующее:

    121217 13:04:56 innobackupex: Starting mysql with options: --defaults-file='/etc/my3.cnf' --socket='/var/lib/mysql3/mysql.sock' --unbuffered --
    121217 13:04:56 innobackupex: Connected to database with mysql child process (pid=64476)
    121217 13:04:58 innobackupex: Starting to lock all tables...
    >> log scanned up to (431009896)
    >> log scanned up to (431009896)
    121217 13:05:08 innobackupex: All tables locked and flushed to disk

    Вот этот lock и привёл, я полагаю, к просадке на графике.

    И далее уже идёт копирование MyISAM-таблиц.

  4. Даже ionice -c 3 innobackupex --throttle=40 серверу плохеет, посещалка падает. Пробовал с --throttle=30, получается очень долго и тоскливо. Прям и не знаю как найти золотую середину :(

  5. БД said

    Уже раз 5 пользовался данным рецептом, всё отлично клонируется. Спасибо за статью!

  6. официальная документация вместо копирования файлов советует использовать

    innobackupex --copy-back

  7. Что-то не клеится у меня с этим xtrabackup-ом: в конце первого этапа пишет вот такую лажу:

    140326 03:02:48 innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt files

    innobackupex: Resuming ibbackup

    xtrabackup: The latest check point (for incremental): '1509903687975'
    >> log scanned up to (1509905539279)
    xtrabackup: Transaction log of lsn (1509807926155) to (1509905539279) was copied.
    innobackupex: Error: mysql child process has died: ERROR 2006 (HY000) at line 13: MySQL server has gone away
    while waiting for reply to MySQL request: 'UNLOCK TABLES;' at /usr/bin/innobackupex line 336.

    B результате дира с файлами бекапа получается какой-то неполной, т.к. на втором этапе xtrabackup ругается на отсутствие файла xtrabackup_checkpoints и дальше работать отказывается.

    И чё с этим делать?

  8. Нарвался на такие грабли:

    [02] Compressing and streaming [03] ...done xtrabackup: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe

    Помогло ulimit -n 102400 перед запуском xtrabackup (увеличние на 2 порядка количества открытых файлов).

  9. Васян said

    Что-то xtrabackup меня не порадовал последний раз. Пытался сделать слейв для mysql-инстанса с 2-мя базами суммарным объемом 133ГБ (du -sh /var/lib/mysql).

    Запустил команду под номером 2 из статьи (там где "UPDATE от 2015-09-10"). Уже третьи сутки на мастере наблюдаю

    >> log scanned up to (325499013557)
    >> log scanned up to (325499020045)
    >> log scanned up to (325499020045)
    >> log scanned up to (325499021077)
    >> log scanned up to (325499023389)
    >> log scanned up to (325499025392)
    >> log scanned up to (325499026544)
    >> log scanned up to (325499031457)
    >> log scanned up to (325499033759)

    На слейве при этом даже файлов никаких еще не создалось. Скорость, конечно, поражает воображение. Нервишки сдали, нажал ctrl-C.

    Сервера совсем не слабые, если что - памяти 192ГБ, SSD-диски, 24 ядра (Intel Xeon X5650 2.67GHz). Правда, база под весьма ощутимой нагрузкой - CPU-usage у сервера где-то около 95% почти половину времени (средний за сутки - 43%)

    Попробую теперь старым добрым mysqldump :(

  10. Васян said

    mysqldump не подвел - всего за 36 минут 36-гиговый файл дампа сделал. Еще 10 минут ушло на заливку на слейв по сети и еще 2 часа 50 минут на импорт на слейве.

    Перконе низачод.

  11. Васян said

    Кстати, про лимиты: в 7-ой CentOS-и чтобы такую лажу починить, нужно сделать такое:

    $ cat /usr/lib/systemd/system/mysqld.service.d/limits.conf
    [Service]
    LimitNOFILE=10000

    # systemctl --system daemon-reload
    # systemctl restart mysqld.service

Some HTML is OK

(required)

(required, but never shared)

, или ответить через trackback.

Страница 1 из 11