展开查看详情
1 . Percona XtraDB Cluster
MySQL Scaling and High Availability with PXC 5.7
Tibor Korocz
Architect
Percona University Budapest
2017.05.11
1 © 2016 Percona
2 .Scaling and High Availability
(application)
2
3 .Scaling and High Availability
(application)
3
4 .Scaling and High Availability
(application)
- Application does not change too often (static)
- If we need more performance we adding more resources
- Easy to scale and achieve High Availability
But what happens with the database?
4
5 .Scaling and High Availability (database)
- We have to distribute all the changes to all the server in
real time.
- It has to be available for all the applications
- The application has to be able to do changes
5
6 .Traditional Replication
server-centric, one server streams the data to another one
6
9 .Async
- Master writes the events in the binary log
- Slave request them
- Master does not know whether or when a slave has
retrieved and processed them
- If the master crashes, transactions that it has committed
might not have been transmitted to any slave
- Failover might cause data loss
9
10 .Data-centric
The data is synchronised between servers, data-centric
10
11 .Virtual Synchronous
- "synchronous" guarantees that if changes happened on
one node of the cluster, they happened on other nodes
“synchronously"
- It is always highly available (no data loss)
- Data replicas are always consistent
- Transactions can be executed on all nodes in parallel
- No complex, time-consuming failovers
11
12 .Virtual Synchronous
12
13 .Certification-based replication
- A transaction executes conventionally until it reaches the commit point,
assuming there is no conflict. This is called optimistic execution.
- Each transaction has a global ordinal sequence number.
- At COMMIT all changes made to the database collected into a write-set
- Sends the write-set to all the other nodes.
- The write-set then undergoes a deterministic certification test, using the
primary keys.
- It determines whether or not the node can apply the write-set.
The procedure is deterministic and all replica receive transactions in the same order. Thus, all nodes reach the
same decision about the outcome of the transaction. The node that started the transaction can then notify the
client application whether or not it has committed the transaction.
13
14 .Traditional Locking
14
15 .Optimistic Locking
15
16 .Galera
- Database Management System (DBMS) The database server
that runs on the individual node.
Galera Cluster can use MySQL or MariaDB.
- wsrep API The interface and the responsibilities
for the database server and replication provider.
- Galera Replication Plugin The plugin that
enables write-set replication service functionality.
- Group Communication plugins
The various group communication systems
available to Galera Cluster. Example: gcomm
16
17 .Percona XtraDB Cluster
Percona XtraDB Cluster is based on Percona Server
running with the XtraDB storage engine. It uses the Galera
library, which is an implementation of the write set
replication (wsrep) API developed by Codership Oy. The
default and recommended data transfer method is via
Percona XtraBackup.
17
18 .Percona XtraDB Cluster
18
19 .Percona XtraDB Cluster
19
20 .Percona XtraDB Cluster
20
21 .Percona XtraDB Cluster
21
22 .Percona XtraDB Cluster
22
23 .Percona XtraDB Cluster
23
24 .Percona XtraDB Cluster
24
25 .Percona XtraDB Cluster
25
26 .Percona XtraDB Cluster
26
27 .Percona XtraDB Cluster
27
28 .Flow Control
- Feedback mechanism for replication process
- Ability of any node in the cluster to ask the rest of the
nodes to pause writes while it catches up
- It can pause the entire cluster!!
wsrep_local_recv_queue > fc_limit
28
29 .Limitations
- Only InnoDB tables are supported (MyISAM alpha)
- Optimistic locking
- The weakest node limits the write performance
- All tables should have a Primary Key.
(wsrep_certify_nonPK=1, in last resort )
- Large transaction are not recommended , specially if you
write multiple nodes simultaneously
- Data hotspots
- Lock Tables, GET_LOCK()…
29
热门城市
