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. Пример:

# rpm -ivh xtrabackup-1.6-245.rhel5.x86_64.rpm
[admin@master] $ innobackupex /backups
 
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2011.  All Rights Reserved.
 
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
 
110623 11:59:51  innobackupex: Starting mysql with options:  --unbuffered --
110623 11:59:51  innobackupex: Connected to database with mysql child process (pid=3685)
110623 11:59:57  innobackupex: Connection to database server closed
IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".
 
innobackupex: Using mysql  Ver 14.14 Distrib 5.5.13, for Linux (x86_64) using readline 5.1
innobackupex: Using mysql server version Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
 
innobackupex: Created backup directory /backups/2011-06-23_11-59-57
110623 11:59:57  innobackupex: Starting mysql with options:  --unbuffered --
110623 11:59:57  innobackupex: Connected to database with mysql child process (pid=3712)
110623 12:00:01  innobackupex: Connection to database server closed
 
110623 12:00:01  innobackupex: Starting ibbackup with command: xtrabackup_55 --backup --suspend-at-end --target-dir=/backups/2011-06-23_11-59-57
innobackupex: Waiting for ibbackup (pid=3724) to suspend
innobackupex: Suspend file '/backups/2011-06-23_11-59-57/xtrabackup_suspended'
 
xtrabackup_55  Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 5242880
110623 12:00:01 InnoDB: Using Linux native AIO
>> log scanned up to (15576575786)
[01] Copying ./ibdata1
     to /backups/2011-06-23_11-59-57/ibdata1
>> log scanned up to (15576821168)
>> log scanned up to (15576993781)
>> log scanned up to (15577223204)
>> log scanned up to (15577401335)
>> log scanned up to (15577646737)
>> log scanned up to (15577864382)
>> log scanned up to (15578032411)
>> log scanned up to (15578302721)
>> log scanned up to (15578496370)
>> log scanned up to (15578695368)
>> log scanned up to (15578966232)
>> log scanned up to (15579121683)
>> log scanned up to (15579340135)
>> log scanned up to (15579572684)
>> log scanned up to (15579801008)
>> log scanned up to (15579918009)
>> log scanned up to (15580129220)
>> log scanned up to (15580377234)
>> log scanned up to (15580543590)
>> log scanned up to (15580811908)
>> log scanned up to (15580992609)
>> log scanned up to (15581162267)
>> log scanned up to (15581314789)
>> log scanned up to (15581469774)
>> log scanned up to (15581662444)
>> log scanned up to (15581858152)
>> log scanned up to (15582046357)
>> log scanned up to (15583450833)
>> log scanned up to (15584545328)
>> log scanned up to (15584847700)
>> log scanned up to (15585508334)
>> log scanned up to (15587171262)
>> log scanned up to (15588573028)
[01]        ...done
 
110623 12:03:15  innobackupex: Continuing after ibbackup has suspended
110623 12:03:15  innobackupex: Starting mysql with options:  --unbuffered --
110623 12:03:15  innobackupex: Connected to database with mysql child process (pid=4879)
>> log scanned up to (15591908670)
110623 12:03:19  innobackupex: Starting to lock all tables...
>> log scanned up to (15597590433)
>> log scanned up to (15598452337)
110623 12:03:29  innobackupex: All tables locked and flushed to disk
 
110623 12:03:29  innobackupex: Starting to backup .frm, .MRG, .MYD, .MYI,
innobackupex: .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV and .opt files in
innobackupex: subdirectories of '/var/lib/mysql'
innobackupex: Backing up files '/var/lib/mysql/mysql/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (72 files)
innobackupex: Backing up files '/var/lib/mysql/performance_schema/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (18 files)
innobackupex: Backing up files '/var/lib/mysql/salesdb/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (210 files)
>> log scanned up to (15598452487)
>> log scanned up to (15598452783)
110623 12:03:43  innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt files
 
innobackupex: Resuming ibbackup
 
>> log scanned up to (15598452993)
xtrabackup: The latest check point (for incremental): '15594901984'
>> log scanned up to (15598452993)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (15574068024) to (15598452993) was copied.
110623 12:03:46  innobackupex: All tables unlocked
110623 12:03:46  innobackupex: Connection to database server closed
 
innobackupex: Backup created in directory '/backups/2011-06-23_11-59-57'
innobackupex: MySQL binlog position: filename 'mysql-bin.000009', position 537035213            mysql
110623 12:03:46  innobackupex: completed OK!

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

[admin@master] $ innobackupex --apply-log /backups/2011-06-23_11-59-57/
 
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2011.  All Rights Reserved.
 
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
 
IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".
 
110623 12:31:28  innobackupex: Starting ibbackup with command: xtrabackup_55
--prepare --target-dir=/backups/2011-06-23_11-59-57
 
xtrabackup_55  Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
xtrabackup: cd to /backups/2011-06-23_11-59-57
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=27443200,start_lsn=(15574068024)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 27443200
110623 12:31:28 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter
110623 12:31:28 InnoDB: The InnoDB memory heap is disabled
110623 12:31:28 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110623 12:31:28 InnoDB: Compressed tables use zlib 1.2.3
110623 12:31:28 InnoDB: Using Linux native AIO
110623 12:31:28 InnoDB: Warning: innodb_file_io_threads is deprecated. Please
use innodb_read_io_threads and innodb_write_io_threads instead
110623 12:31:28 InnoDB: Initializing buffer pool, size = 100.0M
110623 12:31:28 InnoDB: Completed initialization of buffer pool
110623 12:31:28 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 15574068024
110623 12:31:28  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 15579310592 (21 %)
InnoDB: Doing recovery: scanned up to log sequence number 15584553472 (42 %)
InnoDB: Doing recovery: scanned up to log sequence number 15589796352 (64 %)
InnoDB: Doing recovery: scanned up to log sequence number 15595039232 (85 %)
110623 12:31:29  InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
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
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
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
97 98 99
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 15598452993 (99 %)
110623 12:31:38  InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
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
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
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
97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
110623 12:31:39  InnoDB: Waiting for the background threads to start
110623 12:31:40 Percona XtraDB (http://www.percona.com) 1.1.5-20.0 started;
log sequence number 15598452993
 
[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 537035213, file name
./mysql-bin.000009
 
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
110623 12:31:40  InnoDB: Starting shutdown...
110623 12:31:44  InnoDB: Shutdown completed; log sequence number 15598454344
 
110623 12:31:44  innobackupex: Restarting xtrabackup with command:
xtrabackup_55 --prepare --target-dir=/backups/2011-06-23_11-59-57
for creating ib_logfile*
 
xtrabackup_55  Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
xtrabackup: cd to /backups/2011-06-23_11-59-57
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 5242880
110623 12:31:44 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory
parameter)
110623 12:31:44 InnoDB: The InnoDB memory heap is disabled
110623 12:31:44 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110623 12:31:44 InnoDB: Compressed tables use zlib 1.2.3
110623 12:31:44 InnoDB: Using Linux native AIO
110623 12:31:44 InnoDB: Warning: innodb_file_io_threads is deprecated. Please
use innodb_read_io_threads and innodb_write_io_threads instead
110623 12:31:44 InnoDB: Initializing buffer pool, size = 100.0M
110623 12:31:44 InnoDB: Completed initialization of buffer pool
110623 12:31:44  InnoDB: Log file ./ib_logfile0 did not exist: new to be
created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
110623 12:31:45  InnoDB: Log file ./ib_logfile1 did not exist: new to be
created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
110623 12:31:46 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110623 12:31:46  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
110623 12:31:46  InnoDB: Waiting for the background threads to start
110623 12:31:47 Percona XtraDB (http://www.percona.com) 1.1.5-20.0 started;
log sequence number 15598454796
 
[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
 
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
110623 12:31:47  InnoDB: Starting shutdown...
110623 12:31:52  InnoDB: Shutdown completed; log sequence number 15598455780
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 должен быть установлен на обоих серверах.

[avz@slave] mkdir /tmp/db
[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 
[avz@slave] innobackupex --defaults-file=/etc/my2.cnf --apply-log --ibbackup=xtrabackup_55 /tmp/db/2011-06-23_12-52-23
[root@slave] service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
[root@slave] mv /tmp/db/2011-06-23_12-52-23 /var/lib/mysql
[root@slave] chown -R mysql.mysql /var/lib/mysql
[root@slave] service mysqld start
master> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.11.12.13' IDENTIFIED BY 'SomePassw';
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;
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-й ветки, с которой я имел дело). Теперь процедура создания бекапа сразу на другом сервере выглядит так:

[avz@slave] mkdir /tmp/db
[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"
[avz@slave] for bf in `find /tmp/db -iname "*\.qp"`; do echo "processing $bf" ; qpress -d $bf $(dirname $bf) && rm -f $bf; done
[avz@slave] xtrabackup --prepare --target-dir=/tmp/db
[avz@slave] innobackupex --defaults-file=/etc/my2.cnf --apply-log /tmp/db
[root@slave] # service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
[root@slave] # mv /tmp/db/* /var/lib/mysql
[root@slave] # chown -R mysql.mysql /var/lib/mysql
[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 такой последовательностью команд:

[avz@slave] mkdir /tmp/db
[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"
[avz@slave] for bf in `find /tmp/db -iname "*\.qp"`; do echo "processing $bf" ; qpress -d $bf $(dirname $bf) && rm -f $bf; done
[avz@slave] innobackupex --defaults-file=/etc/my.cnf --apply-log --use-memory=190G /tmp/db
[root@slave] # service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
[root@slave] # mv /tmp/db/* /var/lib/mysql
[root@slave] # chown -R mysql.mysql /var/lib/mysql
[root@slave] # service mysqld start

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

150907 13:55:32  innobackupex: Executing FLUSH TABLES WITH READ LOCK...
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

Posted in *nix, Howto.

Tagged with , , .


Разворачивание трафика на основе policy routing

Предстала когда-то задача - выпустить из локальной сети трафик одного девайса (смартфона) так, чтобы в логах сайтов, куда будет сей девайс ходить, светился IP-адрес некоторого заморского сервера, расположенного в Австралии. Смартфон этот никаких средств организации VPN-ов не имел и даже был неспособен работать через прокси, в интернет ходил через Wi-Fi. Локальная сеть с Wi-Fi и смартфоном расположена в Киеве, в Интернет ходит через NAT.
схема сети

  1. На австралийском сервере c именем remote.server.au строим VPN-сервер, например pptpd
  2. На офисном роутере R настраиваем VPN-клиент, например pptp, подключаемся к VPN-серверу, например, так:
    pppd pty 'pptp remote.server.au --nolaunchpppd' call sidney debug dump logfd 2 nodetach

    имя сеанса sidney (после call) должно соответствовать прописанному в файле /etc/ppp/chap-secrets, nodetach --- необязательно, я его использовал для отслеживания процесса.

  3. Маршрутизация работает на основе IP-адреса назначения (destination IP-address), то есть для решения через какой интерфейс отправлять пакет принимается только этот адрес. А в нашей ситуации требуется обратное --- маршрутизировать через Сидней трафик одного только смартфона на основе его IP-адреса, а всех остальных клиентов локальной сети не трогать. Этого можно достичь благодаря одному замечательному умению linux, которое называется policy routing. Создаём еще одну таблицу с произвольным именем (я выбрал avztable) для правил маршрутизации на основе IP-адреса отправителя. Эта новая таблица будет жить параллельно и независимо от основной таблицы маршрутизации с названием main. Для этого в /etc/iproute2/rt_tables, добавляем строчку
    252 avztable
  4. Создаём правило для маршрутизации по source-адресу:
    ip rule add from 192.168.1.55 lookup avztable
  5. Разворачиваем трафик смартфона в туннель путём добавления маршрута по-умолчанию в таблицу avztable:
    ip r a default via 192.168.0.1 table avztable

    Здесь 192.168.0.1 --- адрес VPN-сервера, который становится доступным после поднятия туннеля, задаётся в /etc/pptpd.conf в Сиднее.

  6. В Сиднее добавляем правило для правильной маршрутизации входящего к смартфону трафика. Я для этого наваял такой простенький скрипт и засунул его в cron:
    net='192.168.1.0/24'
    /sbin/ip r s | grep "$net" > /dev/null || {
      gw=`/sbin/ip a s | grep -E "ppp[0-9]" | grep inet | sed -r "s/.*peer[[:space:]]([^/]+)\/.*/\1/"`
        if [ ! -z $gw ]; then
          echo "setting route to net $net via $gw"
          /sbin/ip r a $net via $gw
        fi
    }
    

    Во 2-ой строке проверяем наличие маршрута в таблице маршрутизации, если правила нет, идём дальше. В 3-ей строчке вычисляем IP-адрес VPN-клиента (офисного роутера), который подключился из Киева. В 6-ой строчке собственно добавляем маршрут. После чего австралийский сервер будет знать, что трафик с адресами назначения из сети 192.168.1.0/24 (куда входит наш смартфон), нужно слать в туннель, а не своему default gateway. Правильнее было бы, конечно, вызывать этот скрипт не из cron, а один раз сразу после установки туннеля. Но мне было лениво искать как это сделать автоматически.

  7. В Сиднее проверяем firewall, должно быть что-то такое:
    IPT=/sbin/iptables
    $IPT -A INPUT -p 47 -j ACCEPT
    $IPT -A INPUT -p tcp --dport 1723 -j ACCEPT
    $IPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    $IPT -A FORWARD -s 192.168.1.55 -m comment --comment "phone" -j ACCEPT
    $IPT -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
    

    2-ая и 3-яя строчки нужны для того, чтобы можно было подключиться к VPN-серверу. В 4-ой и 5-ой разрешаем транзитный трафик от и к смартфону. В 6-ой включаем NAT, так чтобы серый адрес смартфона транслировался в в честный адрес австралийского сервера (eth0 - интерфейс в сторону Интернет).

  8. Включаем форфардинг между интерфейсами на сервере в Сиднее:
    sysctl -w net.ipv4.ip_forward = 1

Идём броузером со смартфона для проверки на какой-нибудь looking-glass и проверяём, что он нам показывает IP-адрес австралийского сервера.

Posted in *nix, Howto.


Ремонт компьютеров

На сегодняшний день компьютеры требуются всем и используются во всех областях промышленности и в быту.

Компьютеры нужен и для работы, и для развлечений, для общения и как источник знаний, накопленных человечеством. Сегодня практически в каждой семье есть хотя бы один компьютер, не говоря уже про фирмы и различные организации.

Само собой, что если говорить о довольно сложной технике, она может сломаться в любой неподходящий момент. Многие люди, впервые сталкиваясь с неполадками компьютера, впадают в панику и не знают, что делать и к кому обратиться, чтобы сделать ремонт компьютера.

Куда обратиться?

Объявления с предложениями отремонтировать компьютер можно увидеть на каждом шагу, даже если просто прогуляться по городским улицам. Но качественно обслужить компьютер могут немногие компании. Зачастую свои услуги по ремонту и настройке компьютеров предлагают люди, которые не могут похвастаться хорошим уровнем квалификации, а их знания в сфере IT неглубоки. Такие сервисные инженеры могут знать, что клиент не обладает достаточной компьютерной грамотностью, потому что в этом случае с клиентом легче работать.

Если Вы приобретали уже готовый компьютер, у которого есть срок гарантийного обслуживания и он еще не истёк, у Вас есть возможность обратиться в сервисный центр компании-производителя для осуществления гарантийного ремонта.

У этого способа есть несколько минусов.

  • Заказчику придётся своими силами транспортировать компьютер в центр, обслуживающий его компьютер. И там уже будет проведена экспертиза компьютера.
  • В среднем через недели две вы получите результат, возможно ли отремонтировать компьютер бесплатно по гарантии или ввиду каких-то причин ремонт будет осуществлён за счёт клиента.
  • Нужно заметить, что не всегда сервисные центры соглашаются осуществить ремонт бесплатно, некоторые недобросовестные сотрудники СЦ заранее сообщают, что в поломке виноват сам заказчик и отказывают в гарантийном ремонте по надуманным причинам, предлагая ремонт за деньги.
  • Ремонт компьютера по гарантии может затянуться надолго (даже если он бесплатный), а это часто дополнительные издержки для комании.

Так что если нужно срочно сделать ремонт компьютера, стоит вызвать специалиста на дом или в офис.

Posted in Разное.

Tagged with .


Печать из windows на cups-принтер

Чтобы иметь возможность сетевой печати на компьютере с виндой на принтер, подключенный к linux-машинке с CUPS-ом (Common Unix Printing System), нужно проделать следующее:

  1. Проверить, что в CUPS-е разрешён общий доступ к принтеру. Для этого идём по ссылке http://10.1.1.49:631/printers/scx4200 (IP-адрес и имя принтера заменить в соответствии с Вашим случаем). Должна быть надпись "разрешен совместный доступ".
  2. В windows запускаем "Мастер установки принтеров" - через панель управления или командой
    rundll32 SHELL32, SHHelpShortcuts_RunDLL AddPrinter

    жмём "Далее...", выбираем опцию "Сетевой принтер или принтер подключенный к другому компьютеру", далее выбираем опцию "Подключиться к принтеру в Интернете, домашней сети или в интрасети"

  3. В поле URL вводим адрес принтера, например: http://10.1.1.49:631/printers/scx4200
    настройка принтера для печати через CUPS
    Если спросит про драйвер, выбрать изготовителя "Generic" и модель "MS Publisher Imagesetter". Жмём "Далее..." и принтер готов к использованию.

Если что-то не работает, в проверить следующее:

  1. что в firewall-е на linux-машинке открыт TCP-порт 631 для windows-клиента.
  2. что в винде в Internet Explorer-е ОТКЛЮЧЕН прокси-сервер (пол-часа голову ломал в своё время, пока не допёр посмотреть туда)

Вам необходимо печать буклетов дешево спб? Срочная печать в СПб звоните нам: +7 (812) 380 03 99!

Бесплатный антивирус 360 Total Security скачать для защиты компьютера в реальном времени.

Posted in *nix, Howto, Windows.

Tagged with , , , .