为了改进监控，Percona XtraDB集群实施了一个基础架构，将Galera仪器（mutexes, cond-variables, files, threads）作为其一部分添加到了PERFOMANCE_SCHEMA。尽管mutexes和wsrep状态变量已经是PERFORMANCE_SCHEMA线程的一部分，但线程不是。来自Galera库的mutexes，状态变量，线程和文件也不是PERFORMANCE_SCHEMA的一部分。
一、查看可用的仪器
通过运行可以看到可用仪器的完整列表：
mysql> SELECT * FROM performance_schema.setup_instruments WHERE name LIKE '%galera%' OR name LIKE '%wsrep%';
+----------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+----------------------------------------------------------+---------+-------+
| wait/synch/mutex/sql/LOCK_wsrep_ready | NO | NO |
| wait/synch/mutex/sql/LOCK_wsrep_sst | NO | NO |
| wait/synch/cond/galera/COND_galera_recvbuf | NO | NO |
| wait/io/file/galera/FILE_galera_recordset | YES | YES |
| wait/io/file/galera/FILE_galera_ringbuffer | YES | YES |
| .......................................
| stage/wsrep/wsrep: applier idle | NO | NO |
| stage/wsrep/wsrep: in rollback thread | NO | NO |
| stage/wsrep/wsrep: aborter idle | NO | NO |
| stage/wsrep/wsrep: aborter active | NO | NO |
| memory/sql/wsrep | NO | NO |
+----------------------------------------------------------+---------+-------+
81 rows in set (0.07 sec)下面列车一些最重要的：
Galera所做的两个主要行为是REPLICATION和ROLLBACK。与此相关的互斥锁，状态变量和线程是PERFORMANCE_SCHEMA其中的一部分。
Galera内部使用监视机制来强制事件的排序。这些监视控制事件运用并主要负责不同活动之间的等待。所有这些监视器互斥和条件变量都作为此实现的一部分进行了介绍。
还有很多与接收包和服务信息有关的其他杂项行动。它们所需的互斥锁和状态变量现在也可以看到。管理接收和服务的线程也正在被测试。
此功能已经公开了所有重要的互斥体，即导致锁/线程/文件的状态变量，作为此过程的一部分。
除了公开文件外，它还跟踪写入/读取字节，如文件的状态信息。当Galera使用mmap时，这些数据不会公开给Galera文件。
此外，还有一些线程是短暂的，只有在需要时才会创建，特别是针对SST / IST目的。他们也被追踪，但PERFORMANCE_SCHEMA只有在创建时才会进入表格。
服务器更新到跟踪运行线程状态的Galera特定函数的Stage Info在PerformanceSchema中也是可见的。
二、未披露的
Galera在某些情况下使用客户数据结构(如STL结构)。用于保护这些结构的突变体，不是主线Galera逻辑的一部分，也不是大图中的一部分，也不被跟踪。对于特定于gcomm库的线程也是如此。
Galera在每个监视器内维护一个进程向量，用于其内部图的创建。该处理向量的大小为65K，每个监视器有两个这样的向量。即128 K*3=384 K条件变量。这些信息不会被跟踪以避免占用PerformanceSCHEMA限制和次要的主要关键信息。
