Thứ Sáu, 30 tháng 6, 2017

Install MariaDB Master Slave Replication on Centos 7

1. Install MySQL / MariaDB

Once you have your MariaDB.repo entry, add it to a file under /etc/yum.repos.d/. (We suggest something like /etc/yum.repos.d/MariaDB.repo.)

An example MariaDB.repo file for CentOS 7 is:

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

Installing MariaDB is as simple as running just one command:
yum install MariaDB-server MariaDB-client
If the server already has the MariaDB-Galera-server package installed, you might need to remove it prior to installing MariaDB-server (with 'sudo yum remove MariaDB-Galera-server'). No databases are removed when the MariaDB-Galera-server rpm package is removed, but as with any upgrade, it is best to have backups.

And then start MySQL, now MariaDB:

systemctl start mariadb

Be sure that MySQL/MariaDB starts at boot:

systemctl enable mariadb

To check the status of MySQL/MariaDB:

systemctl status mariadb

To stop MySQL/MariaDB:

systemctl stop mariadb

Check the installation with the command client:

mysql
Secure your Database Server:
mysql_secure_installation
The first and foremost step is to allow mysql default port “3306” through Firewall or Router.

As we use CentOS 7, we can allow the port as shown below.

firewall-cmd --permanent --add-port=3306/tcp
Reload firewall rules using command:

firewall-cmd --reload
Note:

Master: 192.168.235.130
Slave: 192.168.235.131


2. DB TEST

Setting Up a Sample MySQL Database on Master
# git clone https://github.com/datacharmer/test_db
# cd test_db
# mysql < employees.sql

3. Configuring MySQL Server on Master
Edit file /etc/my.cnf.d/server.cnf

##############
log-error = /var/log/mysql/mysql.err
slow-query-log = 1
slow-query-log-file = /var/log/mysql/slow.log
log_bin=binlog
max_connections = 1000
max_allowed_packet=32M
default-storage-engine=innodb
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2

key_buffer = 512M
table_cache = 1000
sort_buffer_size = 3M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
tmp_table_size=20M
max_heap_table_size=20M
thread_cache_size = 64
innodb_buffer_pool_size = 512M
symbolic-links=0
##########################
#master
gtid_domain_id=1
server_id=1
binlog_format=ROW
log_slave_updates=1
expire_logs_days=7
# Allow server to accept connections on all interfaces.
#
bind-address=192.168.235.130


Create the user slave and assign the necessary grants:

MariaDB [(none)]> CREATE USER 'slave'@'localhost' IDENTIFIED BY 'SlavePassword';
MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO slave IDENTIFIED BY 'SlavePassword' WITH GRANT OPTION;
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;
MariaDB [(none)]> SHOW MASTER STATUS;

Take a snapshot of the employees database.
# mysqldump -u root -p employees > employees-dump.sql
After the dump is completed, connect to the database server again to unlock the tables and then exit:

MariaDB [(none)]> UNLOCK TABLES;
MariaDB [(none)]> exit;

Copy the dump to the slave:
#scp employees-dump.sql root@192.168.0.19:/root/
rsync -avz employees-dump.sql hungnv@192.168.235.131:/home/hungnv/

Run the mysql_upgrade procedure to upgrade the system tables
# mysql_upgrade -u root -p

4. Configuring MySQL Server on Slave

Create the user and an empty database:
MariaDB [(none)]> CREATE DATABASE employees;
MariaDB [(none)]> GRANT ALL PRIVILEGES ON employees.* TO 'slave'@'localhost' WITH GRANT OPTION;
MariaDB [(none)]> FLUSH PRIVILEGES;

Restore DATABASE:
# mysql -u root -p employees < employees-dump.sql
Edit file config: /etc/my.cnf.d/server.cnf

[mysqld]
log-error = /var/log/mysql/mysql.err
slow-query-log = 1
slow-query-log-file = /var/log/mysql/slow.log
log_bin=binlog
max_connections = 1000
max_allowed_packet=32M
default-storage-engine=innodb
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2

key_buffer = 512M
table_cache = 1000
sort_buffer_size = 3M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
tmp_table_size=20M
max_heap_table_size=20M
thread_cache_size = 64
innodb_buffer_pool_size = 512M
symbolic-links=0
############
#slave
gtid_domain_id=1
log_slave_updates=1
expire_logs_days=7
server_id=1001
binlog_format=ROW
slave_net_timeout=60
read_only = 1
# Allow server to accept connections on all interfaces.
#
bind-address=192.168.235.131

Restart the database server:

# systemctl restart mariadb

Run the mysql_upgrade procedure to upgrade the system tables (you will be prompted to enter the MariaDB root password):

# mysql_upgrade -u root -p

Start Slave:
MariaDB [(none)]>
CHANGE MASTER TO
MASTER_HOST='192.168.235.130',
MASTER_USER='slave',
MASTER_PASSWORD='SlavePassword',
MASTER_PORT=3306,
MASTER_LOG_FILE='binlog.000003',
MASTER_LOG_POS=67980587,
MASTER_CONNECT_RETRY=10,
MASTER_USE_GTID=current_pos;
MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G;

5. TEST
Add a record to the employees table in the Master server:

MariaDB [(none)]> INSERT INTO employees (emp_no, birth_date, first_name, last_name, gender, hire_date) VALUES (500000, '1983-07-12', 'Dave', 'Null', 'M', '2014-12-12');
Then verify that this change was replicated in the slave:

MariaDB [(none)]> USE employees;
MariaDB [(none)]> SELECT * FROM employees WHERE emp_no=500000;

6. Repair Replication
MASTER LOCK Read & Backup

MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;
MariaDB [(none)]> SHOW MASTER STATUS;
[root@db01 hungnv]# mysqldump -uroot -p employees > employees-dump.sql
scp employees-dump.sql hungnv@192.168.235.131:/home/hungnv/

Recreate the database in slave server:
MariaDB [(none)]>stop slave;
MariaDB [(none)]> drop database employees;
Query OK, 8 rows affected (0.56 sec)
MariaDB [(none)]> create database employees;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> GRANT ALL PRIVILEGES ON employees.* TO 'slave'@'localhost' WITH GRANT OPTION;
MariaDB [(none)]> FLUSH PRIVILEGES;

Restore DB
[root@db02 hungnv]# mysql -uroot -p employees < employees-dump.sql
Start SLAVE

MariaDB [(none)]> CHANGE MASTER TO
    -> MASTER_HOST='192.168.235.130',
    -> MASTER_USER='slave',
    -> MASTER_PASSWORD='SlavePassword',
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE='binlog.000004',
    -> MASTER_LOG_POS=1154;
MariaDB [(none)]> START SLAVE;

Verify:
MariaDB [(none)]> show slave status\G;
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Unlock Master
MariaDB [(none)]>UNLOCK TABLES;









Read More

Thứ Ba, 27 tháng 6, 2017

How To Create SSH Keys With PuTTY

Generating OpenSSH-compatible Keys for Use with PuTTY

To generate a set of RSA keys with PuTTYgen:
  1. Start the PuTTYgen utility, by double-clicking on its .exe file;
  2. For Type of key to generate, select SSH-2 RSA;
  3. In the Number of bits in a generated key field, specify either 2048 or 4096 (increasing the bits makes it harder to crack the key by brute-force methods);
  4. Click the Generate button;
  5. Move your mouse pointer around in the blank area of the Key section, below the progress bar (to generate some randomness) until the progress bar is full;
  6. A private/ public key pair has now been generated;
  7. In the Key comment field, enter any comment you'd like, to help you identify this key pair, later (e.g. your e-mail address; home; office; etc.) -- the key comment is particularly useful in the event you end up creating more than one key pair;
  8. Optional: Type a passphrase in the Key passphrase field & re-type the same passphrase in the Confirm passphrase field (if you would like to use your keys for automated processes, however, you should not create a passphrase);
  9. Click the Save public key button & choose whatever filename you'd like (some users create a folder in their computer named my_keys);
  10. Click the Save private key button & choose whatever filename you'd like (you can save it in the same location as the public key, but it should be a location that only you can access and that you will NOT lose! If you lose your keys and have disabled username/password logins, you will no longer be able log in!);
  11. Right-click in the text field labeled Public key for pasting into OpenSSH authorized_keys file and choose Select All;
  12. Right-click again in the same text field and choose Copy.
NOTE: PuTTY and OpenSSH use different formats for public SSH keys. If the SSH Key you copied starts with "---- BEGIN SSH2 PUBLIC KEY ...", it is in the wrong format. Be sure to follow the instructions carefully. Your key should start with "ssh-rsa AAAA ...."

Save The Public Key On The Server

Now, you need to paste the copied public key in the file ~/.ssh/authorized_keys on your server.
If your SSH folder does not yet exist, create it manually:
    mkdir ~/.ssh
    chmod 0700 ~/.ssh
    touch ~/.ssh/authorized_keys
    chmod 0644 ~/.ssh/authorized_keys
 Paste the SSH public key into your ~/.ssh/authorized_keys file

Create a PuTTY Profile to Save Your Server's Settings

In PuTTY, you can create (and save) profiles for connections to your various SSH servers, so you don't have to remember, and continually re-type, redundant information.
  1. Start PuTTY by double-clicking its executable file;
  2. PuTTY's initial window is the Session Category (navigate PuTTY's various categories, along the left-hand side of the window);
  3. In the Host Name field, enter the IP address of your VPS or its fully qualified domain name (FQDN); see How to Set Up a Host Name with DigitalOcean
  4. Enter the port number in the Port field (for added security, consider changing your server's SSH port to a non-standard port. See Step Five of Initial Server Setup with Ubuntu 12.04
  5. Select SSH under Protocol;
  6. Along the left-hand side of the window, select the Data sub-category, under Connection;
  7. Specify the username that you plan on using, when logging in to the SSH server, and whose profile you're saving, in the Auto-login username field;
  8. Expand the SSH sub-category, under Connection;
  9. Highlight the Auth sub-category and click the Browse button, on the right-hand side of the PuTTY window;
  10. Browse your file system and select your previously-created private key;
  11. Return to the Session Category and enter a name for this profile in the Saved Sessions field, e.g. user@123.456.78.9 or user@host.yourdomain.tld;
  12. Click the Save button for the Load, Save or Delete a stored session area.
Create key on centos
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
55:64:8d:31:2b:ed:c9:1e:e0:c5:2a:90:9a:1c:3e:3d root@localhost
The key's randomart image is:



Read More

Thứ Hai, 26 tháng 6, 2017

How To Install MySQL / MariaDB on CentOS 7

Install MySQL / MariaDB

Installing MariaDB is as simple as running just one command:
yum -y install mariadb-server mariadb
And then start MySQL, now MariaDB:
systemctl start mariadb
Be sure that MySQL/MariaDB starts at boot:
systemctl enable mariadb
To check the status of MySQL/MariaDB:
systemctl status mariadb
To top MySQL/MariaDB:
systemctl stop mariadb
Check the installation with the command client:
mysql
Read More

sử dụng Rsync

Rsync (Remote Sync) là một công cụ dùng để sao chép và đồng bộ file/thư mục được dùng rất phổ biến. Với sự trợ giúp của rsync, bạn có thể đồng bộ dữ liệu trên local hoặc giữa các server với nhau một cách dễ dàng.

Cài đặt Rsync

Rsync được cài đặt dễ dàng với một dòng lệnh:
– Trên Red Hat/CentOS
yum install rsync
– Trên Debian/Ubuntu
apt-get install rsysnc

Sử dụng Rsync

Câu lệnh căn bản của rsync:
rsync options source destination
Trong đó:
  • Source: dữ liệu nguồn
  • Destination: dữ liệu đích
  • Options: một số tùy chọn thêm
Các tham số cần biết khi dùng Rsync
  • -v: hiển thị trạng thái kết quả
  • -r: copy dữ liệu recursively, nhưng không đảm bảo thông số của file và thư mục
  • -a: cho phép copy dữ liệu recursively, đồng thời giữ nguyên được tất cả các thông số của thư mục và file
  • -z: nén dữ liệu khi transfer, tiết kiệm băng thông tuy nhiên tốn thêm một chút thời gian
  • -h: human-readable, output kết quả dễ đọc
  • --delete: xóa dữ liệu ở destination nếu source không tồn tại dữ liệu đó.
  • --exclude: loại trừ ra những dữ liệu không muốn truyền đi, nếu bạn cần loại ra nhiều file hoặc folder ở nhiều đường dẫn khác nhau thì mỗi cái bạn phải thêm --exclude tương ứng.
Rsync không tự động chạy nên thường được dùng kết hợp với crontab.

1. Copy file và thư mục trên local

Copy file trên local
[root@hocvps]# rsync -zvh backup.tar /tmp/backups/

created directory /tmp/backups

backup.tar

sent 14.71M bytes  received 31 bytes  3.27M bytes/sec

total size is 16.18M  speedup is 1.10
Ví dụ trên copy file backup.tar sang thư mục /tmp/backups/ trên cùng một máy. Như bạn thấy thư mục đích chưa có nên rsync tự động tạo trước khi copy.
Copy thư mục trên local
[root@hocvps]# rsync -avzh /root/rpmpkgs /tmp/backups/

sending incremental file list

rpmpkgs/

rpmpkgs/httpd-2.2.3-82.el5.centos.i386.rpm

rpmpkgs/mod_ssl-2.2.3-82.el5.centos.i386.rpm

rpmpkgs/nagios-3.5.0.tar.gz

rpmpkgs/nagios-plugins-1.4.16.tar.gz

sent 4.99M bytes  received 92 bytes  3.33M bytes/sec

total size is 4.99M  speedup is 1.00
Câu lệnh trên copy toàn bộ file từ thư mục /root/rpmpkgs đến thư mục /tmp/backups/ trên cùng một máy.

2. Copy file và thư mục giữa các server

Copy thư mục từ Local lên Remote Server
[root@hocvps]# rsync -avz rpmpkgs/ root@192.168.0.101:/home/

root@192.168.0.101's password:

sending incremental file list

./

httpd-2.2.3-82.el5.centos.i386.rpm

mod_ssl-2.2.3-82.el5.centos.i386.rpm

nagios-3.5.0.tar.gz

nagios-plugins-1.4.16.tar.gz

sent 4993369 bytes  received 91 bytes  399476.80 bytes/sec

total size is 4991313  speedup is 1.00
Lệnh trên copy thư mục rpmpkgs từ Local lên Remote Server có IP 192.168.0.101, lưu ở thư mục /home/
Copy thư mục từ Remote Server về Local
[root@hocvps]# rsync -avzh root@192.168.0.100:/home/tarunika/rpmpkgs /tmp/myrpms

root@192.168.0.100's password:

receiving incremental file list

created directory /tmp/myrpms

rpmpkgs/

rpmpkgs/httpd-2.2.3-82.el5.centos.i386.rpm

rpmpkgs/mod_ssl-2.2.3-82.el5.centos.i386.rpm

rpmpkgs/nagios-3.5.0.tar.gz

rpmpkgs/nagios-plugins-1.4.16.tar.gz

sent 91 bytes  received 4.99M bytes  322.16K bytes/sec

total size is 4.99M  speedup is 1.00
Lệnh trên sẽ copy dữ liệu ở thư mục /home/tarunika/rpmpkgs trên Remote Server 192.168.0.100 về máy Local lưu ở thư mục /tmp/myrpms

3. Rsync qua SSH

Với Rsync, bạn có thể transfer qua giao thức SSH, qua đó dữ liệu được bảo mật an toàn hơn.
Copy file từ Remote Server về Local Server qua SSH
Để xác định giao thức sẽ sử dụng với rsync, bạn cần thêm tùy chọn -e cùng với tên giao thức, ở đây là ssh.
[root@hocvps]# rsync -avzhe ssh root@192.168.0.100:/root/install.log /tmp/

root@192.168.0.100's password:

receiving incremental file list

install.log

sent 30 bytes  received 8.12K bytes  1.48K bytes/sec

total size is 30.74K  speedup is 3.77
Lệnh trên copy file /root/install.log trên Remote Server 192.168.0.100 về thư mục /tmp/ trên máy Local.
Copy file từ Local lên Remote Server qua SSH
[root@hocvps]# rsync -avzhe ssh backup.tar root@192.168.0.100:/backups/

root@192.168.0.100's password:

sending incremental file list

backup.tar

sent 14.71M bytes  received 31 bytes  1.28M bytes/sec

total size is 16.18M  speedup is 1.10

4. Hiển thị tiến trình trong khi transfer dữ liệu với rsync

Để hiển thị tiến độ transfer dữ liệu, bạn có thể sử dụng tùy chọn --progress
[root@hocvps]# rsync -avzhe ssh --progress /home/rpmpkgs root@192.168.0.100:/root/rpmpkgs

root@192.168.0.100's password:

sending incremental file list

created directory /root/rpmpkgs

rpmpkgs/

rpmpkgs/httpd-2.2.3-82.el5.centos.i386.rpm

           1.02M 100%        2.72MB/s        0:00:00 (xfer#1, to-check=3/5)

rpmpkgs/mod_ssl-2.2.3-82.el5.centos.i386.rpm

          99.04K 100%  241.19kB/s        0:00:00 (xfer#2, to-check=2/5)

rpmpkgs/nagios-3.5.0.tar.gz

           1.79M 100%        1.56MB/s        0:00:01 (xfer#3, to-check=1/5)

rpmpkgs/nagios-plugins-1.4.16.tar.gz

           2.09M 100%        1.47MB/s        0:00:01 (xfer#4, to-check=0/5)

sent 4.99M bytes  received 92 bytes  475.56K bytes/sec

total size is 4.99M  speedup is 1.00

5. Sử dụng tùy chọn –include và –exclude

Hai tùy chọn này cho phép chúng ta thêm hoặc bớt file hoặc thư mục trong quá trình đồng bộ dữ liệu.
[root@hocvps]# rsync -avze ssh --include 'R*' --exclude '*' root@192.168.0.101:/var/lib/rpm/ /root/rpm

root@192.168.0.101's password:

receiving incremental file list

created directory /root/rpm

./

Requirename

Requireversion

sent 67 bytes  received 167289 bytes  7438.04 bytes/sec

total size is 434176  speedup is 2.59
Ở ví dụ trên, Rsync include toàn bộ những file hoặc thư mục có tên bắt đầu bởi ký tự ‘R’ và exclude toàn bộ những file hoặc thư mục còn lại.

6. Sử dụng tùy chọn –delete

Nếu muốn xóa một file hoặc thư mục không có ở thư mục nguồn, mà lại xuất hiện ở thư mục đích trong quá trình transfer, bạn hãy sử dụng tùy chọn --delete.
[root@hocvps]#  touch test.txt
[root@hocvps]# rsync -avz --delete root@192.168.0.100:/var/lib/rpm/ .
Password:
receiving file list ... done
deleting test.txt
./
sent 26 bytes  received 390 bytes  48.94 bytes/sec
total size is 45305958  speedup is 108908.55
Server đích đã có file test.txt, trong quá trình đồng bộ với option --delete, file sẽ bị xóa.

7. Giới hạn dung lượng tối đa của file được đồng bộ

Để giới hạn những file lớn được đồng bộ, bạn có thể sử dụng option --max-size
[root@hocvps]# rsync -avzhe ssh --max-size='200k' /var/lib/rpm/ root@192.168.0.100:/root/tmprpm

root@192.168.0.100's password:

sending incremental file list

created directory /root/tmprpm

./

Conflictname

Group

Installtid

Name

Provideversion

Pubkeys

Requireversion

Sha1header

Sigmd5

Triggername

__db.001

sent 189.79K bytes  received 224 bytes  13.10K bytes/sec

total size is 38.08M  speedup is 200.43

8. Tự động xóa dữ liệu nguồn sau khi đồng bộ thành công

Để rsync tự động xóa dữ liệu sau khi đồng bộ lên server đích thành công, bạn có thể sử dụng lựa chọn --remove-source-files
[root@hocvps]# rsync --remove-source-files -zvh backup.tar /tmp/backups/

backup.tar

sent 14.71M bytes  received 31 bytes  4.20M bytes/sec

total size is 16.18M  speedup is 1.10

[root@hocvps]# ll backup.tar

ls: backup.tar: No such file or directory

9. Chạy thử nghiệm Rsync

Nếu bạn không chắc câu lệnh có thực hiện chính xác những gì mong muốn hay không, hãy thêm tùy chọn --dry-run.
Rsync lúc này sẽ không thay đổi gì dữ liệu cả mà chỉ show output mà thôi. Nếu mọi thứ hoạt động ổn, hãy bỏ tùy chọn --dry-run ra khỏi câu lệnh.
root@hocvps]# rsync --dry-run --remove-source-files -zvh backup.tar /tmp/backups/

backup.tar

sent 35 bytes  received 15 bytes  100.00 bytes/sec

total size is 16.18M  speedup is 323584.00 (DRY RUN)

10. Giới hạn bandwidth

[root@hocvps]# rsync --bwlimit=100 -avzhe ssh  /var/lib/rpm/  root@192.168.0.100:/root/tmprpm/
root@192.168.0.100's password:
sending incremental file list
sent 324 bytes  received 12 bytes  61.09 bytes/sec
total size is 38.08M  speedup is 113347.05

IV. Tổng kết

Ứng dụng của Rsync có rất nhiều, bạn có thể đồng bộ hóa file giữa các thư mục, giữa các server qua đó backup server sang một server khác hoặc synchronize real time. Tùy nhu cầu mà bạn hãy ứng dụng Rsync cho hiệu quả.
Chúc bạn thành công.











Read More

MySQL Incremental Backup - Point In Time Backup and Recovery of InnoDB and MyIsam Databases

MySQL Incremental Backup - Point In Time Backup and Recovery of InnoDB and MyIsam Databases

Doing incremental backups is an important requirement for large production databases. Without a safe incremental backup, you can not tell yourself that you have a reliable production database. Because you must have enough data in order to recover your database in emergency cases. After some search on Internet, I could not find any tool that can do a complete incremental backup for MyISAM and InnodB in a mixed environment were applications use both database engines simultaneously (maybe I am not an expert searcher on Google and Internet). So I decided to write this one, but to avoid wasting time and benefit from other open-source solutions, I preferred to add this feature to -automysqlbackup- script that is the best script for full backup in simplicity and widespread use.

Mechanism

We use the Post- and Pre feature of automysqlbackup to do an incremental backup. Before starting a full backup, mysql-backup-pre executes a query to lock the whole database during backup process because we have to freeze the binlog to avoid any change while backup is running. The binlog name and position may not change during backup. The binary log position is very crucial in the subsequent incremental backup process and will be used as a starting point to begin the next incremental backup. After finishing the full backup, mysql-backup-post removes the database lock.
Lock Query: FLUSH TABLES WITH READ LOCK; SELECT SLEEP(86400)
Find Lock Queries:mysql -u[username] -p[pass] -e "show processlist" | grep "SELECT SLEEP(86400)" | awk '{print $1}'

Requirements

  • root privileges to install package and update mysql.conf
  • mysql-community-client package
  • installation automysqlbackup and mysql-incremental

Installation

Install mysql-community-client package for your distro.
Note: after the MySQL installation you must have the 'mysqlshow' command.
Install automysqlbackup:
download the package from https://sourceforge.net/projects/automysqlbackup/
tar -xzf [PathYouSavedTarFile] -C /tmp/
cd /tmp/
./install.sh
During installation of automysqlbackup, you will be asked about path of automysqlbackup.conf and its binary, you can leave defaults without any change.
rm /etc/automysqlbackup/myserver.conf
Install the mysql-incremental: Download the package from https://sourceforge.net/projects/mysqlincrementalbackup/
cd /tmp
wget http://downloads.sourceforge.net/project/mysqlincrementalbackup/mysql-incremental.tar.gz
tar xfz mysql-incremental.tar.gz
cp mysql-incremental /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-incremental
cp mysql-backup-post /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-post
cp mysql-backup-pre /etc/automysqlbackup/
chmod 755 /etc/automysqlbackup/mysql-backup-pre
Update the automysqlbackup.conf:
Find below parameters, uncomment and change them:
        CONFIG_mysql_dump_username='Mysql user name. It must has privileges to get Lock'
 CONFIG_mysql_dump_password='Password'
 CONFIG_backup_dir='The backup directory you want to store full and incremental backup'
 CONFIG_db_names=('databaseName1' 'databaseName2' )
 CONFIG_db_month_names=('databaseName1' 'databaseName2' )
 CONFIG_mysql_dump_master_data=2
 CONFIG_prebackup="/etc/automysqlbackup/mysql-backup-pre"
 CONFIG_postbackup="/etc/automysqlbackup/mysql-backup-post"

Update my.cnf:

Edit the MySQL configuration file:
nano /etc/mysql/my.cnf
1- BinLog Format
Due to some limitation on STATEMENT format, my recommendation is to set ROW based format. For more information please see the 'troubleshoot' section in this howto. You can check the type of binary log format by executing "select @@binlog_format;" query. To modify logbin format , you must add binlog_format = ROW to mysql.conf or my.cnf .
2- binlog_do_db
You must specify the databases that you intend to have the related changes in the binary log. Please note if you do not specify any database, any change on any database will be logged into binary log. In this case, if you chose STATEMENT format, maybe you have some trouble when restoring from incremental backup and binlog files. You can add databases to this option:
binlog_do_db = DATABASENAME1
binlog_do_db = DATABASENAME2
3- expire_logs_days
To have binary log files for a longer time, you can increase this parameter to a higher value. My recommendation is 60 days. So you must add or change it to "expire_logs_days = 60".
4- log-bin
The directory where the binary logs will be stored. In old MySQL versions, mysql-incremenetal might not be able to find the correct path. So if you get an error about this after executing mysql-incremental, you must update mysql-incremental script and set the binary log path.
5- log_slave_updates
If you are setting up mysql-incremental backup on a slave server, you must enable this option. Normally, a slave does not log updates to its own binary log as they were received from a master server. This option tells the slave to log the updates performed by its SQL threads to its own binary log. http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_log-slave-updates

Run automysqlbackup

Run automysqlbackup manually to have at least one full backup from your specified databases.
automysqlbackup
After executing the command successfully, check the /[BackupDirInAutomysqlbackup]/status/backup_info file for the newly added information about the daily backup. For error details, check /var/log/Backup_Post_Pre_log . The backup file will be stored in the directory /[BackupDirInAutomysqlbackup]/daily/[DatabaseName]/ .

Run mysql-incremental

Run mysql-incremental manually now to have at least one hourly backup.
mysql-incremental
In case of an error, the details are logged in the file "/var/log/Backup_Incremental_Log" . The incremental backup files will be stored in the directory /[BackupDirInAutomysqlbackup]/IncrementalBackup/ .

Edit the root crontab

You can schedule mysql-incremental for more than one hour. You can find the total time of full backup from backup_status and then based on that value you set an accurate schedule time. Of course mysql-incremental backup does have a mechanism to find any running full backup before start, so there is no concern about conflict between incremental and full backup.
crontab -e
5 00 * * * root /usr/local/bin/automysqlbackup
25 *  * * * root  /etc/automysqlbackup/mysql-incremental

Restore Database

In order to restore up to a specific time (point in time recovery), first you must restore one full daily backup and then restore sequentially related incremental backup files. To clarify more, here is the steps to recover testDB database. In sample scenario we intend to recover our data up to 2015-5-01 at 2 AM. we have set /backup as our main backup dir and testDB as our target database:
1- mysql -u root -p DatabaseName < /backup/daily/testDB/daily_DatabaseName_2015-05-16_00h05m_Saturday.sql.gz
2- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_00h25m.1
3- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_01h25m.2
4- mysql -u root -p DatabaseNAme < /backup/IncrementalBackup/2015-5-01_Incremental/testDB/testDB_IncrementalBackup_2015-5-01_02h25m.3

Important notes and Troubleshooting

MySQL supports different formats for the binary log. Some Mysql versions use 'statement-based' as binlog format that this type of binlog does have some limitations that we must pay close attention to it when we intent to use it in incremental backup procedure. When mysql is set to statement-base format, it does not able to filter correctly based on databases. If you set 'USE or \u' to change database and then update another database which is not included in binlog-do-db, the statement will be logged in binlog file that it is not desirable state! and will expose some issue when restoring based on specific database and also if you change to another database that is not included in binlog-do-db, and update a database which is included in binlog-do-db, the statement will not logged to binlog file. our purpose from adding databases to binlog-do-db is to filter based on database,but it does not work as expected. If USE or \u is not executed before running queries, mysqlbinlog can not extract 'update queries' related to one database. We will explain more this issue with below scenarioes:
databases: 
 - binlog
     - person (table) 
  - binlog2
     - person (table)

 binlog-do-db=binlog2 (it is supposed only change of this database are logged to binlog file)
--------Scenario 1---------
\u binlog2
insert into person (data) values ('17') ---> loged in binlog  *desired state*
insert into binlog.person (data) values ('25'); ---> logged in binlog (target database is 'binlog' ) *undesired state*
--------Scenario 2---------
\u binlog
insert into person (data) values ('17') ---> is not logged in binlog  *desired state*
insert into binlog2.person (data) values ('25'); ---> is not logged in binlog (target database is 'binlog2' ) *undesired state* because the binlog2 database
is begin changed, so we want to have this change,but it will not logged in logbin file
--------Scenario 3---------
if you just connect to database without any USE or \u statement, all of updates on any databases will be logged, but mysqlbinlog can not able to filter
based on specific database, so that is not desirable state for our purpose in incremental backup. Using USE or \u before executing update queries, is very
important. Because mysqlbinlog finds update queries based on USE statement in binlog file.

Work around for the mentioned issue

1) By defining users on databases in a way that each user only has access to one database to update (application user) and when connection to database, the name of database must be specified. Of course most of applications do have a config file that the credentials and name of database are set in it, so in that case you will not have a cross-access on databases and there will not be concern on using "\USE or \u".
2) If you use row-based binlog format, so all of mentioned issue will be gone. in other words,row-based format is much more proper method for binlog. https://dev.mysql.com/doc/refman/5.1/en/replication-options-binary-log.html

Log Files

I did try to log everything in a log file so you can find enough information in the logs:
/var/log/Backup_Post_Pre_log/var/log/Backup_Incremental_Log/[SpecifiedBackupDirInAutomysqlbackup.conf]/status/backup_info
The file "backup_info" contains the detailed info about the backup and when the backup finished (Times are in Unix Time format). It contains the binlog name and position of the timepoint the backup started, the type of backup, number of backups since the last full backup and the duration of the backup.
Sample backup_info:
1431043501,mysql-bin.000026,120,Daily,2015-05-08,0,24
1431044701,mysql-bin.000026,120,Hourly,2015-05-08,1,1
Here are description of the different values:
 1th) 1431043501 : indicates the time when the backup has been finished. You can run date --date @1431043501 command on the server the backup has been done to view it in human readable format.
 2th) Mysql-bin.000026 : indicates the binary log name that backup up to this file has been done.
 3th) 120 : indicates the position of binlog  that backup up to this position in binary log has been done.
 4th) Daily/Hourly: indicates type of backup. Daily does mean the full backup by automysqlbackup script and Hourly is done by mysql-incremental script.
 5th) 2015-05-08: The date that backup has been done. This date will be used in creating directory for incremental backup and also as a base for restore hourly backups. In restoring procedure, first a full backup is restored and then sequentially other incremental backup are restored.
 6th) 0 : indicates number of backups from previous full backup. 0 does mean the backup is full and others mean hourly. This number is very important in restoring procedure.
 7th) 24: The backup duration in second.

Bug Report

You can report bugs or give your suggestions and reviews at https://sourceforge.net/projects/mysqlincrementalbackup .
Read More