8.replication

[email protected]

Hệ quản trị cơ sở dữ liệuHệ quản trị cơ sở dữ liệu

Dư Phương HạnhBộ môn Hệ thống thông tin

Khoa CNTT, trường Đại học Công

nghệ

Đại học Quốc gia Hanoi

ReplicationReplication

Hệ quản trị CSDL @ BM HTTT2

OutlineOutline

Replication concepts and principles Setting up replication on master and slave servers Managing replication Replication settings

Read more at:

http://mysql-tools.com/en/replication-in-mysql.html


Replication concepts and

principles


IntroduceIntroduce

Beside performing regular backups of your

databases, you can also replicate your databases.

It means you maintain a copy of the database that

is kept up-to-date (synchronized) with the original

database. If the original database becomes

unavailable, the replicated database can continue

to provide users immediate access to the same

data with a minimal amount of downtime.


Replicating MySQL Databases

Updates made to one database copy are

automatically propagated to all the other replicas.

Generally, one of the replicas is designated as

the master where Updates are directed to the master

while read queries can be addressed to either the

master or the slaves.

If replicas other than master handle the updates, then

keeping the replicas identical becomes more

complex.


Benefits of database replication

Availability: Any replica can be used as a "hot" backup.

– If the master database becomes unavailable, this replica can

take over and can be designated as the master. The failures

can be fixed and the failed replica can rejoin as a slave

replica.

Backups: Replicas can be used as active backups and

can be used to perform tedious offline backups to file

systems without locking up the primary instance.


Benefits of database replication

Load Balancing: Replicas can serve split loads, also

called load balancing, for heavily used databases.

– Read queries can be distributed to the different replicas while

updates are handled by the master. This scenario works well

when the number of read queries is far greater than the

number of update queries.

Proximity: Some replicas can be closer to users leading

to improved response time.

Security: It is harder for malicious users to damage all

the replicas.


Availability

One database is

the master while

the other is

designated as a

slave. Only

updates to the

master are

logged.


Load Balancing

Read queries are

directed to either

the master or any

of the replicas

while update

queries are

directed only to

the master.


MySQL Replication Model

MySQL replication is based on a number of principles:

1.Replication is a one-way, asynchronous process changes

are always propagated from the master server to the slave

server, but never the other way around.

2.The primary MySQL server acts as the Master server, and the

servers that contain the copied databases are considered

the Slave servers.

3.Data always moves from the master server to the slave server.

As a result, only databases on the master server should be

updated. The updates are then propagated to the slave servers



4. The master server must be configured with a user account that

grants replication privileges to the slave server. The account

allows the slave server to access the master server in order to

receive updates.

5. Replication is based on the master database server recording

all updates in a binary log binary logging must be enabled

on the master server. The logged updates are used to

synchronize the database on the slave server.

6. To avoid conflicts, update queries are directed to the master

while read queries can either go to the master or to the slaves.



7. The replicas connect to the master to read the binary log

and then apply the updates to catch up with the master.

8. The slave server uses replication coordinates to track

updates.

– The coordinates are based on the name of a binary log file on

the master server and the position in that file. The file and

position represent where MySQL left off when the last update

was performed on the slave server. The coordinates - along

with other logon information - are stored in the master.info file

on the slave host.



9. Each server that participates in the replication process must

be assigned a unique numerical server ID. You assign the

ID by specifying the server-id option in the [mysqld] section

of the option file for each server.

10. A master server can replicate data to one or more slave

servers.

11. To set up replication, the master server and slave server

must begin with databases in a synchronized state. In other

words, the databases to be replicated must be identical

when replication is initiated.



12. No slave server can ever have two master servers.

13. It is generally best to have the master server and slave

servers run the same version of MySQL.

14. There are two core types of replication format

– Statement Based Replication (SBR): replicates entire SQL

statements,

– Row Based Replication (RBR): replicates the changed rows

– You may also use a third variety, Mixed Based Replication

(MBR), which is the default mode within MySQL 5.1.14 and later.


Setting up Replication

Enable binary logging on the master server.

Make a backup of the master database.

Start a new binary log immediately after making the

backup.

Set up a user account on the master server that

grants replication privileges to the slave server. The

account allows the slave server to access the

master server in order to receive updates.


Setting up Replication (2)

Assign a unique numerical server ID to each server

that participates in the replication process.

Block all updates to the master.

Create a Slave instance.

Load the backup of the master database into the slave

Apply the updates from the binary log to the slave to

sync up with the master.

Get both the master and slave running.


Replication Files on the Slave (1)

When replication is implemented, the slave server

maintains a set of files to support the replication. MySQL

automatically creates the three types of files on the slave

server:

1.<host>-relay-bin.<extension>:Contains the statements

to be used to synchronize the replicated database with

the database on the master server, and then it is deleted.

– The relay log files receive their data from the binary log

files on the master server.


Replication Files on the Slave (2)

2. master.info: Contains connection information such

as the master server hostname, user account and

its password. It also maintains information about

the last binary log file on the master server to be

accessed and the position in that file.

3. relay-log.info: Contains information about the relay

log files and tracks the last position in those files in

which the replicated database was updated.


Implementing Replication - Details


Set up Replication User (on Master)

To allow a master server to replicate data to a slave

server, you must set up a user account on the

master server.

The slave server then uses that account to establish

a connection to the master server


Set up Replication User (on Master)

GRANT REPLICATION SLAVE ON *.* TO '<slave account>'@'<slave

host>' IDENTIFIED BY '<password>';

The REPLICATION SLAVE privilege at the global level allows all

changes to a database to be replicated to the copy of the database

on the slave server.

TO clause defines the username on the account and host from

which that account can connect. This is the host where the slave

server resides.

The IDENTIFIED BY clause then identifies the password that

should be used when the slave server logs on to the master server.


Making Initial Backup Make a backup of the databases that you want to replicate. Use

the --master-data option in the mysqldump command. The --

master-data option adds a CHANGE MASTER statement similar

to the following to your backup file:

CHANGE MASTER TO MASTER_LOG_FILE='mastsrv-

bin.000201', MASTER_LOG_POS=64;

CHANGE MASTER statement identifies the binary log file and

the position in that file at the time that the backup file is created.

You use this information later when you set up replication on the

slave server to synchronize the slave server with the master

server.


Configuration Changes on Master (1) Shut down the master server.

Modify the [mysqld] group in the option file on the master

server to specify a server ID for the master server.

– The master server and any slave servers must each be assigned a

unique numerical ID.

If you don't want to replicate a specific database, such as the

mysql or test databases, you can add a binlog-ignore-

db option for each database to prevent changes to that

database from being logged to the binary file.

Restart the master server.


Configuration Changes on Master (2)[mysqld]

log-bin

binlog-db=sakila

binlog-ignore-db=mysql

binlog-ignore-db=test

server-id=masterserverID;

log-bin option specifies

that binary logging should

be enabled.

Two binlog-ignore-db options specify

that changes to the mysql and test

databases should not be logged to

the binary files.

The server-id option specifies the

numbered ID for the master server.

Note: If you use an existing option

file, a server-id may already be

present. If multiple options are

specified and the numerical IDs are

different, replication might not work.


Configuration Changes on the Slave Shut down the slave server.

Modify the option file on the slave server so that

the [mysqld] section includes the following settings:

server-id=<slave server id>

Make certain that this server ID is different from the

master server ID and different from any other slave

server IDs. Also be sure that this is the only server-

id option defined on the slave server.

Restart the slave server.


Restore Backup on Slave

Use the backup file created on Master to load the

databases into the slave server


Set up Connection to Master Specify the settings that

will be used for the slave

server to connect to the

master server and

determine which binary log

file to access. Launch the

mysql client utility on the

slave server, and execute

CHANGE MASTER

statement.

Syntax

CHANGE MASTER TO

MASTER_HOST='<master host>',

MASTER_USER='<user account>',

MASTER_PASSWORD='<passwor

d>',

MASTER_LOG_FILE='<log file>',

MASTER_LOG_POS=<position>;

The slave server adds this

information to the master.info file,

which is used when connecting to

the master server.


Start Replication on Slave

The final is to start the replication process on the

slave server. To do so, execute the following SQL

statement on the slave server:

START SLAVE;

The statement initiates the threads that connect

from the slave server to the master server.


Verifying Replication

Once replication is set up, update a table on the master

server and then confirm whether that change has been

replicated to the slave server.

To support administering replication, MySQL provides a

number of SQL statements that allow you to view information

about the replication environment or take a specific action.

MySQL supports statements for both the master server and

the slave server.



Managing the Master Server:

– RESET MASTER Statement

– SHOW MASTER STATUS Statement

– SHOW SLAVE HOSTS Statement



Managing the Slave Server:

– SHOW SLAVE HOSTS Statement

– CHANGE MASTER Statement

– RESET SLAVE Statement

– SHOW SLAVE STATUS Statement

– START SLAVE Statement

– STOP SLAVE Statement


Exercise

Thực hiện đồng bộ hoá CSDL test của bài trước.

– Cấu hình slave server giả lập trên 1 máy tính

– Bật chế độ --log-bin trên master server

– Backup CSDL test trên master server với option –master-

data

– Tạo người dùng cho slave

– Slave server thực hiện restore CSDL test

– Khai báo thông tin để truy cập bin log thực hiện đồng bộ hoá

– Bắt đầu tiến hành đồng bộ hoá

8.replication

Technology