percona_mysql
percona-toolkit工作原理
percona-toolkit工作原理Percona Toolkit是一个用于MySQL数据库管理和维护的工具集，它由多个工具组成，包括备份、复制、性能分析、数据修复等功能。
Percona T oolkit的工作原理如下：1. 收集MySQL数据库信息：Percona Toolkit通过使用MySQL的SHOW命令和信息模式（information_schema）来收集数据库的元数据和性能指标。
这些信息包括表和索引的大小、查询的执行计划、锁定和等待事件等。
2. 分析MySQL数据库信息：Percona Toolkit可以对收集到的MySQL数据库信息进行分析，以便更好地了解数据库的性能瓶颈和问题。
例如，Percona Toolkit可以分析查询执行计划，以确定是否存在慢查询，或者分析锁定和等待事件，以确定是否存在锁定争用。
3. 优化MySQL数据库性能：Percona Toolkit提供了一些工具，可以帮助优化MySQL数据库的性能。
例如，pt-query-digest可以分析慢查询日志，并生成报告，以便识别和优化慢查询。
pt-index-usage可以分析索引使用情况，并生成报告，以便识别和优化索引。
4. 维护MySQL数据库：Percona Toolkit还提供了一些工具，可以帮助维护MySQL数据库。
例如，pt-online-schema-change可以在不中断服务的情况下修改表结构，pt-table-checksum可以检查数据在主从服务器之间的一致性，pt-table-sync可以同步数据在主从服务器之间的差异。
总之，Percona Toolkit通过收集、分析和优化MySQL数据库的信息，帮助用户更好地管理和维护MySQL数据库。
Percona Xtrabackup 备份mysql数据库使用说明
Percona Xtrabackup 备份mysql数据库使用说明关于Percona Xtrabackup的说明：Percona Xtrabackup是世界上唯一一款开源免费的mysql热备软件，可在使用Innodb和Xtradb存储引擎的数据库上无阻塞、无中断的执行备份，此软件的优势有：备份快速而可靠；备份时可执行无中断转储；节约磁盘空间和网络带宽；自动备份验证；因为快速恢复所带来的更高的运行时间；它可执行连续、压缩且增量的mysql备份。
此外，它可以支持针对Innodb、Xtradb和Haildb存储引擎的完整无阻塞的备份，并且它可以通过执行短暂的写锁对以下存储引擎备份：Merge、MyISAM、Archive，备份内容包括分区表、触发器、数据库参数。
Percona Xtrabackup的特性：创建Innodb热备份而不用停止数据库；可使用增量备份；连续的压缩的mysql备份到其他服务器；在在线的mysql服务间转移表；轻松创建新的mysql从复制；备份mysql时可以不用增加服务器的负载。
使用说明：Innobackupex工具是一个封装了xtrabackup的C程序脚本，它通过整合了xtrabackup和其他诸如文件拷贝和连续性的功能而带来了很多便利，它使得我们可以对与模型定义一起的Innodb/xtradb表、MyISAM表和其他服务的部分进行基于时间点的备份。
连接服务需要的相关权限：当创建、准备一个备份和恢复时，xtrabackup需要能够连接到数据库服务器和在datadir目录和服务器上进行操作相关的权限，需要的权限诸如：允许用户在操作系统上对某个目录或服务进行读、写、执行的操作，这是在系统级别对用户的应用。
当使用xtrabackup和innobackupex时，有两个角色需要明确：一个支持程序的用户——系统用户，一个执行数据库服务的用户——数据库用户，尽管这两个可能用户相同，但是却是不同的用户。
MySQL数据库性能监控与优化的工具推荐
MySQL数据库性能监控与优化的工具推荐近年来，随着互联网的快速发展和信息技术的不断创新，各类网站和应用程序的数据库需求越来越大。
而数据库作为应用系统中最关键的组成部分之一，其性能直接关系到整个系统的运行效率和用户体验。
为了及时发现和解决数据库性能问题，提高系统的稳定性和性能，数据库性能监控与优化工具应运而生。
本文将介绍几种常用的MySQL数据库性能监控与优化工具，为用户提供参考。
一、MySQL性能监控工具1. MySQL Enterprise MonitorMySQL Enterprise Monitor是由MySQL AB开发的一款强大的性能监控工具。
该工具提供了丰富的监控指标和图表，可以实时监测MySQL服务器的性能参数，包括CPU利用率、内存使用、磁盘IO、查询响应时间等。
同时，它还支持报警功能，可以在数据库性能出现异常时发送警报通知管理员及时处理。
2. Percona Monitoring and Management (PMM)PMM是由Percona开发的一套开源的MySQL性能监控工具。
它基于Prometheus和Grafana构建，提供了丰富的监控指标和仪表盘展示，用户可以通过图表直观地了解数据库的性能状况。
PMM还提供了Query Analytics功能，可以对SQL查询进行分析，帮助用户优化查询性能。
3. Navicat MonitorNavicat Monitor是一款功能强大的MySQL性能监控工具，为用户提供实时的性能监控和优化建议。
它可以监测MySQL服务器的关键指标，如查询执行时间、连接数、线程状态等，并生成相应的报表和图表展示。
此外，Navicat Monitor还支持远程监控，用户可以通过网络访问监控数据，方便远程管理。
二、MySQL性能优化工具1. MySQLTunerMySQLTuner是一款Perl脚本工具，用于分析MySQL服务器的配置和性能瓶颈，并给出相应的优化建议。
mysql pxc 集群原理 -回复
mysql pxc 集群原理-回复MySQL PXC（Percona XtraDB Cluster）集群原理PXC是一个基于MySQL InnoDB引擎的高可用性和可扩展性的集群解决方案。
它通过使用多主复制和基于Galera集群的同步复制来确保数据的一致性和高可用性。
本文将详细介绍PXC集群的原理，并逐步回答相关问题。
1. 什么是PXC集群？PXC集群是一个由多个MySQL节点组成的集群，并通过相互之间的同步复制来实现数据的分布和高可用性。
每个节点都是一个独立的数据库服务器，具有自己的内存、CPU和磁盘资源。
2. PXC集群使用了什么技术来实现数据的同步复制？PXC集群使用了Galera集群技术来实现同步复制。
Galera集群是一个开源的同步复制解决方案，它通过在每个节点上应用相同的写操作来保证数据的一致性。
3. PXC集群是如何处理写入操作的？当一个节点接收到一个写入操作时，它会将该操作应用到其本地的数据库副本上，并将该写入操作发送给其他节点。
其他节点也会将该写入操作应用到它们的本地数据库副本上。
只有当大多数节点确认已经应用了该写入操作时，该操作才会被认为是提交成功的。
4. PXC集群是如何处理读取操作的？PXC集群允许所有节点都可用于处理读取操作。
当一个读取请求到达集群时，该请求会被转发到任意一个节点上进行处理。
由于所有节点都有相同的数据副本，所以无论请求转发到哪个节点，返回的结果应保持一致。
5. PXC集群中的节点如何通信？PXC集群中的节点使用多播和单播两种方式进行通信。
在多播方式下，节点通过组播地址将状态变更、写入操作和心跳消息发送给其他节点。
而在单播方式下，节点通过互相通信的IP地址来进行节点之间的通信。
6. PXC集群中的节点如何检测其他节点的可用性？每个节点都会定期发送心跳消息给其他节点。
通过检测其他节点是否有响应来确定其是否可用。
如果一个节点无法检测到其他节点的心跳消息，那么它会认为其他节点已经失效，并从集群中移除。
MySQL中的数据库监控工具推荐
MySQL中的数据库监控工具推荐引言在当今的信息时代，数据的重要性和价值不言而喻。
对于一个企业或组织来说，数据库是最重要的资产之一，因此，保障数据库的稳定运行和及时发现潜在问题变得尤为重要。
为了实现这一目标，数据库监控工具成为数据库管理员的得力助手。
本文将介绍一些在MySQL数据库中常用的监控工具，以及它们的特点和优势。
一、MySQL Enterprise Monitor (MEM)MySQL Enterprise Monitor是MySQL官方推出的一款功能强大的数据库监控工具。
它能够自动收集和分析数据库的性能数据，并提供实时的警报和建议，以便管理员及时采取措施避免潜在问题。
MEM支持图形化的界面展示，可以让管理员直观地了解数据库的运行状况。
MEM的优势在于其丰富的性能监控指标和灵活的警报机制。
通过MEM，管理员可以监控到数据库的CPU使用率、磁盘IO、内存消耗等关键指标。
此外，MEM还可以设置自定义的警报规则，管理员可以根据实际需求设置合适的阈值来提醒和防范潜在问题。
二、Percona Monitoring and Management (PMM)PMM是Percona公司提供的一套开源的数据库监控工具。
它基于Grafana和Prometheus等开源软件，并结合Percona公司在MySQL性能优化方面的经验，提供了一套功能完善的MySQL监控解决方案。
PMM具有良好的扩展性和灵活性。
管理员可以根据自身需求选择监控的指标和频率，并可以自定义仪表盘来展示关注的数据。
此外，PMM还提供了多种报表和图表，方便管理员对数据库性能进行深入分析。
三、ZabbixZabbix是一款开源的企业级监控软件，它支持多种数据库的监控，包括MySQL。
通过在被监控的数据库上安装代理程序，Zabbix能够实时获取数据库的性能数据，并进行分析和报警。
Zabbix的优势在于其强大的自定义能力和丰富的监控方式。
管理员可以根据具体需求自定义监控项和触发条件，定制化监控方案。
percona toolkit 使用手册
percona toolkit 使用手册Percona Toolkit 是一套用于管理和维护MySQL 数据库的高性能工具。
以下是Percona Toolkit 的使用手册：1、安装Percona T oolkit在安装Percona Toolkit 之前，请确保您已经安装了Percona Server for MySQL。
您可以从Percona 官方网站下载Percona Toolkit，并按照安装向导进行安装。
2、常用命令和工具Percona Toolkit 提供了一系列有用的命令和工具，可以帮助您管理和维护MySQL 数据库。
以下是一些常用命令和工具的简要说明：pt-table-checksum：用于检查MySQL 数据库中表的一致性。
pt-table-sync：用于修复表的不一致性。
pt-heartbeat：用于监控MySQL 主从复制的状态。
pt-mysql-summary：用于显示MySQL 服务器的概要信息，包括查询、慢查询等。
pt-query-digest：用于分析MySQL 服务器的慢查询日志，找出性能瓶颈。
3、使用示例以下是一些使用Percona Toolkit 的示例：•检查表的一致性：sqlpt-table-checksum --user=root --password=password--host=localhost --port=3306 --databases=mydatabase•修复表的不一致性：csspt-table-sync --user=root --password=password --host=localhost --port=3306--fix--databases=mydatabase•监控主从复制状态：csspt-heartbeat --user=root --password=password --host=master--port=3306--logdir=/tmp/heartbeat4、参考文档和资源Percona Toolkit 的官方文档提供了更详细的使用说明和技巧，您可以访问Percona 官方网站获取最新版本的文档。
MySQL性能分析工具
常用MySQL性能分析工具工具助力优化数据库性
能
使用分析工具来监控和分析MySQL性能可以有助于发现潜在的性能问题并优化数据库性能。
以下是一些常见的MySQL性能分析工具：
1.MySQL Enterprise Monitor：这是MySQL官方提供的企业级监控工具，
可以监控数据库服务器的性能和状态，提供详细的性能报告和报警功能。
2.Percona Toolkit：这是一个开源的工具包，用于监控、分析和管理
MySQL数据库。
它可以帮助DBA进行日常管理和维护，包括数据库备份、恢复、优化等操作。
3.MySQL Query Browser：这是一个免费的MySQL查询浏览器，可以执行
SQL查询并显示结果。
它还提供了简单的数据库管理功能，如创建表、插入数据、更新数据等。
4.MySQL Administrator：这是MySQL官方提供的服务器管理工具，可以
帮助DBA管理数据库服务器的配置、用户、权限等。
它还包括了一些基本的监控功能，如图形化的状态变量显示。
5.MySQL迁移工具箱：这是一个用于将数据从其他数据库系统迁移到
MySQL的开源工具箱。
它可以帮助DBA在迁移过程中进行数据转换、优化和监控。
这些分析工具可以帮助DBA进行MySQL性能监控和分析，但具体的工具选择和使用方法会因情况而异。
在使用这些工具时，建议先了解它们的特性和使用方法，然后结合实际需求进行选择和使用。
另外，还可以参考MySQL的最佳实践和经验总结，以及使用第三方备份工具来定期备份MySQL数据库和日志文件，以防止数据丢失或损坏。
mysql xtrabackup8.0原理
mysql xtrabackup8.0原理XtraBackup 是Percona 提供的一个开源备份工具，用于MySQL 和MariaDB 数据库。
XtraBackup 8.0 是XtraBackup 的一个版本，针对MySQL 8.0 进行了优化和改进。
以下是XtraBackup 8.0 的主要工作原理：锁定机制：XtraBackup 使用了一种称为“共享锁”的机制来锁定数据库，以防止数据在备份过程中被修改。
这种锁允许读取操作继续进行，同时阻止写入操作，从而确保备份的一致性。
物理备份：XtraBackup 执行的是物理备份，这意味着它复制数据库的文件，而不是复制数据库的结构或逻辑数据。
这种备份方法的好处是它非常快速和灵活，因为它不依赖于数据库的特定结构或查询。
增量备份：XtraBackup 支持增量备份和差异备份，这意味着它可以只备份自上次备份以来发生更改的数据。
这大大减少了备份时间和数据量，尤其是在大型数据库中。
文件格式：备份的文件通常使用xtrabackup 特定的格式（通常为 .xtrabackup_binary），以避免直接访问原始数据文件。
这种格式允许XtraBackup 在恢复过程中进行优化和额外的处理。
数据恢复：一旦完成备份，XtraBackup 提供了一个工具来帮助恢复数据。
恢复过程可以快速完成，并且可以针对特定的时间点进行恢复，这使得数据恢复更为灵活。
兼容性：由于XtraBackup 使用的是物理备份方法，它可以与多种存储引擎兼容，包括InnoDB、MyISAM 等。
总的来说，XtraBackup 8.0 的工作原理是利用锁定机制、物理备份方法、增量备份支持以及特定的文件格式来快速、一致地备份MySQL 8.0 数据库，并提供灵活的数据恢复选项。
PostgreSQL与MySQL对比（转载）
PostgreSQL与MySQL对⽐（转载）所有数据库对⽐可以参考：原⽂地址：⽐较版本：PostgreSQL 11 VS MySQL5.7（innodb引擎） Oracle官⽅社区版版权情况：PostgreSQL 11（免费开源）、MySQL5.7 Oracle官⽅社区版（免费开源）1. CPU限制PGSQL没有CPU核⼼数限制，有多少CPU核就⽤多少MySQL能⽤128核CPU，超过128核⽤不上2. 配置⽂件参数PGSQL⼀共有255个参数，⽤到的⼤概是80个，参数⽐较稳定，⽤上个⼤版本配置⽂件也可以启动当前⼤版本数据库MySQL⼀共有707个参数，⽤到的⼤概是180个，参数不断增加，就算⼩版本也会增加参数，⼤版本之间会有部分参数不兼容情况3. 第三⽅⼯具依赖情况PGSQL只有⾼可⽤集群需要依靠第三⽅中间件，例如：patroni+etcd、repmgrMySQL⼤部分操作都要依靠percona公司的第三⽅⼯具（percona-toolkit，XtraBackup），⼯具命令太多，学习成本⾼，⾼可⽤集群也需要第三⽅中间件，官⽅MGR集群还没成熟4. ⾼可⽤主从复制底层原理PGSQL物理流复制，属于物理复制，跟SQL Server镜像/AlwaysOn⼀样，严格⼀致，没有任何可能导致不⼀致，性能和可靠性上，物理复制完胜逻辑复制，维护简单MySQL主从复制，属于逻辑复制，（sql_log_bin、binlog_format等参数设置不正确都会导致主从不⼀致）⼤事务并⾏复制效率低，对于重要业务，需要依赖 percona-toolkit的pt-table-checksum和pt-table-sync⼯具定期⽐较和修复主从⼀致主从复制出错严重时候需要重搭主从MySQL的逻辑复制并不阻⽌两个不⼀致的数据库建⽴复制关系5. 从库只读状态PGSQL系统⾃动设置从库默认只读，不需要⼈⼯介⼊，维护简单MySQL从库需要⼿动设置参数super_read_only=on，让从库设置为只读，super_read_only参数有bug，链接：6. 版本分⽀PGSQL只有社区版，没有其他任何分⽀版本，PGSQL官⽅统⼀开发，统⼀维护，社区版有所有功能，不像SQL Server和MySQL有标准版、企业版、经典版、社区版、开发版、web版之分国内外还有⼀些基于PGSQL做⼆次开发的数据库⼚商，例如：Enterprise DB、瀚⾼数据库等等，当然这些只是⼆次开发并不算独⽴分⽀MySQL由于历史原因，分裂为三个分⽀版本，MariaDB分⽀、Percona分⽀、Oracle官⽅分⽀，发展到⽬前为⽌各个分⽀基本互相不兼容Oracle官⽅分⽀还有版本之分，分为标准版、企业版、经典版、社区版7. SQL特性⽀持PGSQLSQL特性⽀持情况⽀持94种，SQL语法⽀持最完善，例如：⽀持公⽤表表达式（WITH查询）MySQLSQL特性⽀持情况⽀持36种，SQL语法⽀持⽐较弱，例如：不⽀持公⽤表表达式（WITH查询）关于SQL特性⽀持情况的对⽐，可以参考：8. 主从复制安全性PGSQL同步流复制、强同步（remote apply)、⾼安全，不会丢数据PGSQL同步流复制：所有从库宕机，主库会罢⼯，主库⽆法⾃动切换为异步流复制（异步模式），需要通过增加从库数量来解决，⼀般⽣产环境⾄少有两个从库⼿动解决：在PG主库修改参数synchronous_standby_names =''，并执⾏命令： pgctl reload ，把主库切换为异步模式主从数据完全⼀致是⾼可⽤切换的第⼀前提，所以PGSQL选择主库罢⼯也是可以理解MySQL增强半同步复制，mysql5.7版本增强半同步才能保证主从复制时候不丢数据mysql5.7半同步复制相关参数：参数rpl_semi_sync_master_wait_for_slave_count 等待⾄少多少个从库接收到binlog，主库才提交事务，⼀般设置为1，性能最⾼参数rpl_semi_sync_master_timeout 等待多少毫秒，从库⽆回应⾃动切换为异步模式，⼀般设置为⽆限⼤，不让主库⾃动切换为异步模式所有从库宕机，主库会罢⼯，因为⽆法收到任何从库的应答包⼿动解决：在MySQL主库修改参数rpl_semi_sync_master_wait_for_slave_count=09. 多字段统计信息PGSQL⽀持多字段统计信息MySQL不⽀持多字段统计信息10. 索引类型PGSQL多种索引类型（btree , hash , gin , gist , sp-gist , brin , bloom , rum , zombodb , bitmap，部分索引，表达式索引）MySQLbtree 索引，全⽂索引（低效），表达式索引(需要建虚拟列)，hash 索引只在内存表11. 物理表连接算法PGSQL⽀持 nested-loop join 、hash join 、merge joinMySQL只⽀持 nested-loop join12. ⼦查询和视图性能PGSQL⼦查询，视图优化，性能⽐较⾼MySQL视图谓词条件下推限制多，⼦查询上拉限制多13. 执⾏计划即时编译PGSQL⽀持 JIT 执⾏计划即时编译，使⽤LLVM编译器MySQL不⽀持执⾏计划即时编译14. 并⾏查询PGSQL并⾏查询（多种并⾏查询优化⽅法），并⾏查询⼀般多见于商业数据库，是重量级功能MySQL有限，只⽀持主键并⾏查询15. 物化视图PGSQL⽀持物化视图MySQL不⽀持物化视图16. 插件功能PGSQL⽀持插件功能，可以丰富PGSQL的功能，GIS地理插件，时序数据库插件，向量化执⾏插件等等MySQL不⽀持插件功能17. check约束PGSQL⽀持check约束MySQL不⽀持check约束，可以写check约束，但存储引擎会忽略它的作⽤，因此check约束并不起作⽤（mariadb ⽀持）18. gpu 加速SQLPGSQL可以使⽤gpu 加速SQL的执⾏速度MySQL不⽀持gpu 加速SQL 的执⾏速度19. 数据类型PGSQL数据类型丰富，如 ltree，hstore，数组类型，ip类型，text类型，有了text类型不再需要varchar，text类型字段最⼤存储1GBMySQL数据类型不够丰富20. 跨库查询PGSQL不⽀持跨库查询，这个跟Oracle 12C以前⼀样MySQL可以跨库查询21. 备份还原PGSQL备份还原⾮常简单，时点还原操作⽐SQL Server还要简单，完整备份+wal归档备份（增量）假如有⼀个三节点的PGSQL主从集群，可以随便在其中⼀个节点做完整备份和wal归档备份MySQL备份还原相对不太简单，完整备份+binlog备份（增量）完整备份需要percona的XtraBackup⼯具做物理备份，MySQL本⾝不⽀持物理备份时点还原操作步骤繁琐复杂22. 性能视图PGSQL需要安装pg_stat_statements插件，pg_stat_statements插件提供了丰富的性能视图：如：等待事件，系统统计信息等不好的地⽅是，安装插件需要重启数据库，并且需要收集性能信息的数据库需要执⾏⼀个命令：create extension pg_stat_statements命令否则不会收集任何性能信息，⽐较⿇烦MySQL⾃带PS库，默认很多功能没有打开，⽽且打开PS库的性能视图功能对性能有影响（如：内存占⽤导致OOM bug）23. 安装⽅式PGSQL有各个平台的包rpm包，deb包等等，相⽐MySQL缺少了⼆进制包，⼀般⽤源码编译安装，安装时间会长⼀些，执⾏命令多⼀些MySQL有各个平台的包rpm包，deb包等等，源码编译安装、⼆进制包安装，⼀般⽤⼆进制包安装，⽅便快捷24. DDL操作PGSQL加字段、可变长字段类型长度改⼤不会锁表，所有的DDL操作都不需要借助第三⽅⼯具，并且跟商业数据库⼀样，DDL操作可以回滚，保证事务⼀致性MySQL由于⼤部分DDL操作都会锁表，例如加字段、可变长字段类型长度改⼤，所以需要借助percona-toolkit⾥⾯的pt-online-schema-change⼯具去完成操作将影响减少到最低，特别是对⼤表进⾏DDL操作DDL操作不能回滚25. ⼤版本发布速度PGSQLPGSQL每年⼀个⼤版本发布，⼤版本发布的第⼆年就可以上⽣产环境，版本迭代速度很快PGSQL 9.6正式版推出时间：2016年PGSQL 10 正式版推出时间：2017年PGSQL 11 正式版推出时间：2018年PGSQL 12 正式版推出时间：2019年MySQLMySQL的⼤版本发布⼀般是2年~3年，⼀般⼤版本发布后的第⼆年才可以上⽣产环境，避免有坑，版本发布速度⽐较慢MySQL5.5正式版推出时间：2010年MySQL5.6正式版推出时间：2013年MySQL5.7正式版推出时间：2015年MySQL8.0正式版推出时间：2018年26. returning语法PGSQL⽀持returning语法，returning clause ⽀持 DML 返回 Resultset，减少⼀次 Client <-> DB Server 交互MySQL不⽀持returning语法27. 内部架构PGSQL多进程架构，并发连接数不能太多，跟Oracle⼀样，既然跟Oracle⼀样，那么很多优化⽅法也是相通的，例如：开启⼤页内存MySQL多线程架构，虽然多线程架构，但是官⽅有限制连接数，原因是系统的并发度是有限的，线程数太多，反⽽系统的处理能⼒下降，随着连接数上升，反⽽性能下降⼀般同时只能处理200 ~300个数据库连接28. 聚集索引PGSQL不⽀持聚集索引，PGSQL本⾝的MVCC的实现机制所导致MySQL⽀持聚集索引29. 空闲事务终结功能PGSQL通过设置 idle_in_transaction_session_timeout 参数来终⽌空闲事务，⽐如：应⽤代码中忘记关闭已开启的事务，PGSQL会⾃动查杀这种类型的会话事务MySQL不⽀持终⽌空闲事务功能30. 应付超⼤数据量PGSQL不能应付超⼤数据量，由于PGSQL本⾝的MVCC设计问题，需要垃圾回收，只能期待后⾯的⼤版本做优化MySQL不能应付超⼤数据量，MySQL⾃⾝架构的问题31. 分布式演进PGSQLHTAP数据库：cockroachDB、腾讯Tbase分⽚集群： Postgres-XC、Postgres-XLMySQLHTAP数据库：TiDB分⽚集群：各种各样的中间件，不⼀⼀列举32. 数据库的⽂件名和命名规律PGSQLPGSQL在这⽅⾯做的⽐较不好，DBA不能在操作系统层⾯（停库状态下）看清楚数据库的⽂件名和命名规律，⽂件的数量，⽂件的⼤⼩⼀旦操作系统发⽣⽂件丢失或硬盘损坏，⾮常不利于恢复，因为连名字都不知道PGSQL表数据物理⽂件的命名/存放规律是：在⼀个表空间下⾯，如果没有建表空间默认在默认表空间也就是base⽂件夹下，例如：/data/base/16454/3599base：默认表空间pg_default所在的物理⽂件夹16454：表所在数据库的oid3599：就是表对象的oid，当然，⼀个表的⼤⼩超出1GB之后会再⽣成多个物理⽂件，还有表的fsm⽂件和vm⽂件，所以⼀个⼤表实际会有多个物理⽂件由于PGSQL的数据⽂件布局内容太多，⼤家可以查阅相关资料当然这也不能全怪PGSQL，作为⼀个DBA，时刻做好数据库备份和容灾才是正道，做介质恢复⼀般是万不得已的情况下才会做MySQL数据库名就是⽂件夹名，数据库⽂件夹下就是表数据⽂件，每个表都有对应的frm⽂件和ibd⽂件，存储元数据和表/索引数据，清晰明了，做介质恢复或者表空间传输都很⽅便33. 权限设计PGSQLPGSQL在权限设计这块是⽐较坑爹，抛开实例权限和表空间权限，PGSQL的权限层次有点像SQL Server，db=》schema=》object要说权限，这⾥要说⼀下Oracle，⽤Oracle来类⽐在ORACLE 12C之前，实例与数据库是⼀对⼀，也就是说⼀个实例只能有⼀个数据库，不像MySQL和SQL Server⼀个实例可以有多个数据库，并且可以随意跨库查询⽽PGSQL不能跨库查询的原因也是这样，PGSQL允许建多个数据库，跟ORACLE类⽐就是有多个实例（之前说的实例与数据库是⼀对⼀）⼀个数据库相当于⼀个实例，因为PGSQL允许有多个实例，所以PGSQL单实例不叫⼀个实例，叫集簇（cluster），集簇这个概念可以查阅PGSQL的相关资料PGSQL⾥⾯⼀个实例/数据库下⾯的schema相当于数据库，所以这个schema的概念对应MySQL的database注意点：正因为是⼀个数据库相当于⼀个实例，PGSQL允许有多个实例/数据库，所以数据库之间是互相逻辑隔离的，导致的问题是，不能⼀次对⼀个PGSQL集簇下⾯的所有数据库做操作必须要逐个逐个数据库去操作，例如上⾯说到的安装pg_stat_statements插件，如果您需要在PGSQL集簇下⾯的所有数据库都做性能收集的话，需要逐个数据库去执⾏加载命令⼜例如跨库查询需要dblink插件或fdw插件，两个数据库之间做查询相当于两个实例之间做查询，已经跨越了实例了，所以需要dblink插件或fdw插件，所以道理⾮常简单权限操作也是⼀样逐个数据库去操作，还有⼀个就是PGSQL虽然像SQL Server的权限层次结构db=》schema=》object，但是实际会⽐SQL Server要复杂⼀些，还有就是新建的表还要另外授权在PGSQL⾥⾯，⾓⾊和⽤户是⼀样的，对新⼿⽤户来说有时候会傻傻分不清，也不知道怎么去⽤⾓⾊，所以PGSQL在权限设计这⼀块确实⽐较坑爹MySQL使⽤mysql库下⾯的5个权限表去做权限映射，简单清晰，唯⼀问题是缺少权限⾓⾊user表db表host表tables_priv表columns_priv表34. 发展历史PGSQL在1995年，开发⼈员Andrew Yu和Jolly Chen在Postgres中添加了⼀个SQL（Structured Query Language，结构化查询语⾔）翻译程序，该版本叫做Postgres95，在开放源代码社区发放。
MySQL与PostgreSQL相比哪个更好？
MySQL与PostgreSQL相⽐哪个更好？⽹上已经有很多拿PostgreSQL与MySQL⽐较的⽂章了，这篇⽂章只是对⼀些重要的信息进⾏下梳理。
在开始分析前，先来看下这两张图：MySQLMySQL声称⾃⼰是最流⾏的开源数据库。
LAMP中的M指的就是MySQL。
构建在LAMP上的应⽤都会使⽤MySQL，如WordPress、Drupal等⼤多数php开源程序。
MySQL最初是由MySQL AB开发的，然后在2008年以10亿美⾦的价格卖给了Sun公司，Sun公司⼜在2010年被Oracle 收购。
Oracle⽀持MySQL的多个版本：Standard、Enterprise、Classic、Cluster、Embedded与Community。
其中有⼀些是免费下载的，另外⼀些则是收费的。
其核⼼代码基于GPL许可，由于MySQL被控制在Oracle，社区担⼼会对MySQL的开源会有影响，所以开发了⼀些分⽀，⽐如： MariaDB和Percona。
PostgreSQLPostgreSQL标榜⾃⼰是世界上最先进的开源数据库。
PostgreSQL的⼀些粉丝说它能与Oracle相媲美，⽽且没有那么昂贵的价格和傲慢的客服。
最初是1985年在加利福尼亚⼤学伯克利分校开发的，作为Ingres数据库的后继。
PostgreSQL是完全由社区驱动的开源项⽬。
它提供了单个完整功能的版本，⽽不像MySQL那样提供了多个不同的社区版、商业版与企业版。
PostgreSQL基于⾃由的BSD/MIT许可，组织可以使⽤、复制、修改和重新分发代码，只需要提供⼀个版权声明即可。
MySQL与PostgreSQL的对⽐MySQL的背后是⼀个成熟的商业公司，⽽PostgreSQL的背后是⼀个庞⼤的志愿开发组。
这使得MySQL的开发过程更为慎重，⽽PostgreSQL的反应更为迅速。
这样的两种背景直接导致了各⾃固有的优点和缺点。
PostgreSQL相对于MySQL的优势1)不仅仅是关系型数据库除了存储正常的数据类型外，还⽀持存储：array，不管是⼀位数组还是多为数组均⽀持json(hStore)和jsonb，相⽐使⽤text存储接送要⾼效很多json和jsonb之间的区别jsonb和json在更⾼的层⾯上看起来⼏乎是⼀样的，但在存储实现上是不同的。
Percona监控MySQL模板详解
Percona监控MySQL模板详解InnoDB Adaptive Hash Index显⽰了“⾃适应哈希索引”的使⽤情况,哈希索引只能⽤来搜索等值的查询.# Hash table size 17700827, node heap has 35112 buffer(s)# 3577.42 hash searches/s, 507.49 non-hash searches/sHash Index Cells Total ⾃适应哈希表的槽数=innodb_buffer_pool_size/256Hash Index Cells Used ⽤到⾃适应哈希表的查询个数InnoDB Buffer Pool Activity显⽰Innodb缓冲池的内部活动,页的创建,读取,写⼊.如果有突然的增加或者减少,需要检查应⽤Pages CreatedPages ReadPages WrittenInnoDB Buffer PoolPool Size InnoDB缓冲池的页数量,每页⼤⼩16KDatabase Pages 数据页⼤⼩Free Pages 空闲页⼤⼩Modified Pages "脏"数据页.如果脏数据页太多,则需要检查磁盘IO状态.InnoDB Checkpoint AgeUncheckpointed Bytes显⽰了未写⼊磁盘的数据量.如果该值的⼤⼩接近innodb_log_file_size * n 的总⼤⼩,则需要增加innodb_log_file_size的值,但是要注意,如果发⽣宕机,则需要更长的回复时间.(从redolog恢复)InnoDB Current Lock WaitsInnoDB Lock Wait Secs显⽰每秒处于锁等待的innodb事务总数.如果有⼀个⾮常⼤的值,应该检查LOCK WAIT transactions,请看下⾯的模板InnoDB I/OFile Reads 显⽰每秒⽂件的读次数File Writes 显⽰每秒⽂件的写次数Log Writes 写⽇志的次数File Fsyncs 调⽤fsync()函数的次数.与innodb_flush_log_at_trx_commit值的设置有关.InnoDB I/O Pending显⽰了InnoDB挂起的同步或异步IO操作.如果挂起的操作太多,则需要更⼤的RAM,更⼤的缓冲池,更快的磁盘.Pending Aio Log IosPending Aio Sync IosPending Buf Pool FlushesPending Chkp WritesPending Ibuf Aio ReadsPending Log FlushePending Log WritesPending Normal Aio ReadsPending Normal Aio WritesInnoDB Insert Buffer插⼊缓冲,并不是缓存的⼀部分,⽽是物理页,对于⾮聚集索引的插⼊或更新操作,不是每⼀次直接插⼊索引页.⽽是先判断插⼊的⾮聚集索引页是否在缓冲池中.如果在,则直接插⼊,如果不再,则先放⼊⼀个插⼊缓冲区中.然后再以⼀定的频率执⾏插⼊缓冲和⾮聚集索引页⼦节点的合并操作.使⽤条件:⾮聚集索引,⾮唯⼀Ibuf Inserts插⼊的记录数Ibuf Merged合并的页的数量Ibuf Merges合并的次数如果merges/merged的值等于3/1,则代表插⼊缓冲对于⾮聚集索引页的IO请求⼤约降低了3倍InnoDB Insert Buffer UsageIbuf Cell Count分段⼤⼩Ibuf Used Cells插⼊缓冲区的⼤⼩Ibuf Free Cells"⾃由列表"的长度InnoDB Internal Hash Memory Usage显⽰了InnoDB内部各种哈希结构(不可⼈⼯⼲预),占⽤的内存⼤⼩.Adaptive Hash Memory⾃适应哈希索引占⽤的内存⼤⼩Page Hash MemoryDictionary Cache MemoryFile System MemoryLock System MemoryRecovery System MemoryThread Hash MemoryInnoDB Lock StructuresInnoDB Lock Structs该图形显⽰了在innodb内部有多少锁结构(不是死锁).这⼤致与当前事务锁住的⾏数有关系.可以⽤来判断是否存在锁争⽤.对于数量多少算好或者算坏,没有硬性的规定.实际情况下,⼤量的事务在等待锁,很明显,该值越⼩越好.这个数据来源是SHOW ENGINE INNODB STATUS;# 23 lock struct(s), heap size 3024, undo log entries 27# LOCK WAIT 12 lock struct(s), heap size 3024, undo log entries 5# LOCK WAIT 2 lock struct(s), heap size 368InnoDB Log相关变量:innodb_log_buffer_sizeInnoDB Log Buffer SizeLog Bytes WrittenLog sequence number当前⽇志的位置Log Bytes FlushedLog flushed up to⽇志已经刷新的位置Unflushed Log是log_bytes_written与log_bytes_flushed的差值,表⽰⽇志缓存区⾥还有多少数据没被刷新到⽇志⽂件⾥.如果这个差值超过了innodb_log_buffer_size设置的30%,则需要考虑是否加⼤该参数值.InnoDB Memory AllocationTotal memory allocated 8824815616; in additional pool allocated 0Total Mem AllocInnoDB申请的总内存量,单位字节Additional Pool Alloc分配给额外内存的总量,单位字节InnoDB Row Lock TimeInnoDB Row Lock Time该模板读取的Innodb_row_lock_time状态变量,表⽰InnoDB引擎在每次申请数据⾏锁定时等待的总时间(以毫秒为单位). InnoDB Row Lock WaitsInnoDB Row Lock Waits读取的Innodb_row_lock_waits状态变量,表⽰InnoDB经过这么长时间才获得⼀个⾏锁.(毫秒)InnoDB Row OperationsNumber of rows inserted 50678311, updated 66425915, deleted 20605903, read 454561562⼤致能表现InnoDB内部的操作Row ReadRow DeletedRow UpdatedRow InsertedInnoDB Semaphores Wait TimeInnoDB Sem Wait Time Ms显⽰当前正在等待互斥量的InnoDB线程的等待时间的总耗时(毫秒).分析:正常情况下,InnoDB Semaphores Wait Time和 InnoDB Semaphores Waits应该是空的.除⾮服务器运⾏着⾼并发的⼯作负载,它促使InnoDB采取让操作系统等待的措施.信息位于SHOW ENGINE INNODB STATUS的SEMAPHORES⽚段.相关php脚本代码部分如下:elseif (strpos($line, 'seconds the semaphore:') > 0) {# --Thread 907205 has waited at handler/ha_ line 7156 for 1.00 seconds the semaphore:increment($results, 'innodb_sem_waits', 1);increment($results, 'innodb_sem_wait_time_ms', to_int($row[9]) * 1000);}其中innodb_sem_waits的值是多少,表⽰有多少线程在等待,⽽innodb_sem_wait_time_ms表⽰所有线程等待的时间,默认单位是秒,在脚本中乘以1000,所以监控图中的单位是毫秒.应对这个问题InnoDB采取多阶段等待策略.⾸先,尝试对锁进⾏循环等待.如果经过了⼀个预设的循环等待周期(innodb_sync_spin_loops = 30,当前配置⽂件默认为30次)之后还没有成功,就会退到更昂贵更复杂的等待阵列⾥,如果并发量太⼤的话,则导致系统负载突增.循环等待的成本相对⽐较低,但是需要不停地检查⼀个资源是否被锁定,消耗CPU周期,也就是说,当另外⼀条线程能处理事情时,循环等待也会独占处理器.循环等待的替换⽅案就是让操作系统做上下⽂切换(等待阵列),每秒钟⼏千次的切换会引发⼤量的系统开销.解决办法根据具体的应⽤,调整参数;或者优化应⽤,减少并发.InnoDB Semaphores WaitsInnoDB Sem Waits显⽰当前正在等待互斥量的InnoDB线程的数量.InnoDB Semaphores显⽰innodb内部的信号活动状态.包括Mutex spin waits,RW-shared spins,RW-excl spins等各种信号量的数量总和.Spin RoundsInnoDB内部预设的互斥量信号数量Spin WaitsInnoDB内部对锁进⾏循环等待的数量(与innodb_sync_spin_loops参数有关)Os Wait系统等待事务退到操作系统的等待阵列的数量在⾼并发的情况,会发现这个值有尖峰状,不稳定.图像主要显⽰了,不合理的设计情况下,不同的连接类型之间的⾏锁或互斥锁的争⽤.InnoDB Tables In Use# mysql tables in use 2, locked 2InnoDB Tables In Use所有事务⽤到的表的数量InnoDB Locked Tables所有事务锁定的表的数量InnoDB Transactions Active/Locked该图显⽰了InnoDB事务的状态数量.Active Transactions正在执⾏的事务数量Locked Transactions锁住的事务数量Current Transactions当前的事务数量(包括not started,ACTIVE,...等各种状态)not started # 事务已经提交到磁盘ACTIVE # 正在执⾏的事务Read Views(待更新)read views open inside InnoDBInnoDB Transactions显⽰了InnoDB事务相关的信息InnoDB TransactionsInnoDB内部的事务总数.由以下数值计算出:Trx id counter 89F56195 # 当前事务ID,每创建⼀个新事务就会累加Purge done for trx's n:o < 89F5609C undo n:o < 0 -- InnoDB清除旧版本MVCC时所⽤的事务ID.这个ID之前的⽼版本数据已经清除.该数值就是由当前事务ID减去清除旧数据的事务ID再由⼗六进制转成⼗进制的值.(参考ss_get_mysql_stats.php脚本902⾏)History List历史记录的长度.位于InnoDB数据⽂件的撤销空间⾥的未清除事务的数⽬.当⼀个事务执⾏了更新并提交后,这个数字就会累加,当清除进程移除⼀个旧版本数据时,它就会递减.MyISAM Indexs显⽰了在MyISAM索引上的读写情况Key Reads Requests从键缓存读出索引块的读操作的次数Key Reads从磁盘读出索引块的读操作次数Key Write Requests向键缓存写⼀个索引块的请求的个数Key Writes把索引块写⼊磁盘的写操作的次数MyISAM Key CacheKey Buffer Size键缓存⼤⼩Key Buf Bytes Used同Key_blocks_used变量键缓存⾥已经被使⽤的缓存块的个数Key Buf Bytes Unused同Key_blocks_unused键缓存⾥尚未被使⽤过的缓存块的个数MySQL Binary/Relay LogsBinlog Cache Use保存在⼆进制⽇志缓存⾥的事务的个数Binlog Cache Disk Use超过binlog_cache_size设置的缓存⼤⼩,使⽤磁盘临时⽂件的事务的个数Binlog Log Space⼆进制⽇志的⼤⼩Relay Log Space中继⽇志的⼤⼩如果Binlog Cache Disk Use/Binlog Cache Use的值较⼤,那么应该尝试增加binlog_cache_size的⼤⼩.但是,也不要期望改善过多,如果写临时⽂件的数量从每秒1个减少到每分钟⼀个,这已经证明优化的⾜够好了.没必要耗费⼤量的内存,来处理binlog_cache_size中的事务.MySQL Command Counts命令计数器,显⽰了MySQL(在过去1秒内)执⾏各种命令的次数Questions记录了服务器收到的查询和命令的总数.(Com_*变量的总数不⼀定相等.)Com SelectCom DeleteCom InsertCom UpdateCom ReplaceCom LoadCom Delete MultiCom Insert SelectCom Update MultiCom Replace SelectMySQL ConnectionsMax Connections 允许同时保持在打开状态的客户连接的最⼤个数Max Used Connections 此前曾同时打开处于打开状态的连接的最⼤个数Aborted Clients 因客户端没有正确地关闭⽽被丢弃的连接的个数Aborted Connects 试图连接MySQL服务器但没有成功的次数Threads Connectd 现在正处于打开状态的连接的个数Connections 试图连接MySQL服务器的尝试次数MySQL Files and TablesTable CacheOpen Tables 当前处于打开状态的数据表的个数.不包括TEMPORARYOpen Files 当前处于打开状态的⽂件的个数,如果与open_files_limit接近,则应该加⼤open_files_limit的值.Opened TablesMySQL服务器已打开的数据表总数(包括显式定义的临时表).如果这个值很⾼,应该慎重考虑,是否加⼤数据表缓存(table_open_cache).MySQL HandlerHandler_writer 向数据表⾥插⼊⼀个数据⾏的请求的个数Handler_update 对数据表⾥的⼀个数据⾏进⾏修改的请求的个数Handler_delete 从数据表删除⼀个数据⾏的请求的个数Handler_read_first 读取索引中第⼀个索引项的请求的个数Handler_read_key 根据⼀个索引值⽽读取⼀个数据⾏的请求的个数Handler_read_next 按索引顺序读取下⼀个数据⾏的请求的个数Handler_read_prev 按索引逆序读取前⼀个数据⾏的请求的个数Handler_read_rnd 根据某个数据⾏的位置⽽读取该数据⾏的请求的个数Handler_read_rnd_next 读取下⼀个数据⾏的请求的个数.如果这个数字很⾼,就说明有很多语句需要通过全表扫描才能完成或有很多查询没有使⽤适当的索引MySQL Network TrafficBytes Send 发送字节数Bytes Received 收到字节数MySQL ProcesslistState Closing Tables该线程将已更改的表数据刷新到磁盘，并关闭已使⽤的表。
Percona MySQL的Cacti监控模板
Percona MySQL的Cacti监控模板本文描述MySQL监控模板的安装指南及MySQL图表的例子，说明MySQL监控模板收集和显示了哪些信息。
安装说明MySQL监控模板是一套PHP脚本，从MySQL服务器收集信息并返回给Cacti，脚本通过建立MySQL的普通连接来收集信息。
强烈建议为每个需要监控的MySQL服务器创建相同的MySQL用户名和密码，这样易于安装和配置。
否则，需要为不同的MySQL服务器自定义模板配置。
参考下面权限的详细信息。
该脚本需要能够从Cacti服务器连接到MySQL服务器，可以提供mysql客户端命令行测试是否可连接，MySQL连接问题可以参考MySQL手册。
安装步骤：l在每个需要监控的MySQL服务器上创建具有SUPER和PROCESS权限的MySQL用户。
例如：GRANTSUPER, PROCESS ON *.* TO 'cacti'@'%' IDENTIFIED BY "s3c ret";l如果需要从Percona工具箱监控复制，必须授权heartbeat表的SELECT权限。
例如：GRANT SELECT ONpercona.heartbeat TO 'cacti'@'%';l拷贝ss_get_mysql_stats.php到Cactiz的 scripts/目录。
l其它步骤参考安装文档。
User权限上面提到的用户权限在通常case中是足够的。
下面的列表说明数据收集脚本执行的查询，以及在不想要时如何禁用：SHOW /*!50002 GLOBAL */ STATUS该查询不需要特殊权限，是核心功能需要的。
SHOW VARIABLES该查询不需要特殊权限，是核心功能需要的。
SHOW ENGINES该查询不需要特殊权限，是核心功能需要的。
SHOW SLAVE STATUS该查询需要SUPER或REPLICATION CLIENT权限。
MySQL数据库的监控和性能调优工具
MySQL数据库的监控和性能调优工具MySQL是当前最流行的关系型数据库管理系统之一，被广泛用于各个领域的应用开发中。
而对于数据库的监控和性能调优是保障其稳定性和高效性的重要环节。
在这篇文章中，我们将探讨一些常用的MySQL数据库监控和性能调优工具。
一、监控工具1. MySQL Enterprise MonitorMySQL Enterprise Monitor是由MySQL官方提供的一款强大的监控工具。
它可以提供对MySQL服务器性能和状态的实时监控，包括查询的运行时间、慢查询、锁等信息。
此外，还可以通过邮件、报警等方式及时通知管理员发现和解决问题。
该工具具有用户友好的界面，非常适合企业级的MySQL数据库监控和管理。
2. Percona Monitoring and ManagementPercona Monitoring and Management（简称PMM）是一套由Percona提供的开源监控和管理工具。
它基于Grafana和Prometheus构建，可以实时监控MySQL数据库的性能，并提供丰富的性能指标和监控报表。
PMM提供了可视化的仪表盘，使得管理员可以方便地查看数据库的状态、性能和负载情况，以及进行趋势分析和容量规划。
3. 数据库性能分析器数据库性能分析器是一种用于监控和分析数据库性能的工具。
它可以帮助开发人员识别慢查询、瓶颈和优化机会。
对于MySQL数据库而言，比较常用的性能分析器有工具集合pt-query-digest和MySQL自带的性能分析工具sysbench。
这些工具可以帮助您找到数据库的性能热点和瓶颈，并给出相应的优化建议。
二、性能调优工具1. MySQL TunerMySQL Tuner是一款免费的开源工具，用于对MySQL服务器进行性能调优。
它可以分析服务器的当前配置和性能指标，并给出优化建议。
MySQL Tuner提供了一系列的检查项，包括缓冲区大小、查询缓存、连接数、表结构等方面的优化建议。
数据库备份的方法
数据库备份的方法一、介绍数据库备份是指将数据库中的数据和结构复制到另一个位置或媒介上，以便在出现故障或数据丢失时恢复数据。
备份是数据库管理中非常重要的一个环节，也是保障数据安全性的关键步骤。
二、选择备份工具1. MySQL BackupMySQL Backup是MySQL官方提供的备份工具，可以通过命令行或者图形界面进行操作。
它支持多种备份方式，包括逻辑备份和物理备份。
2. mysqldumpmysqldump是MySQL自带的备份工具，可以通过命令行进行操作。
它支持逻辑备份和部分物理备份。
3. xtrabackupxtrabackup是Percona提供的MySQL备份工具，支持物理备份和增量备份，并且可以在运行时对数据库进行热备。
4. pg_dumppg_dump是PostgreSQL自带的备份工具，可以通过命令行进行操作。
它支持逻辑备份和部分物理备份。
5. pg_basebackuppg_basebackup也是PostgreSQL自带的备份工具，支持物理备份和增量备份，并且可以在运行时对数据库进行热备。
三、选择合适的存储方式1. 本地存储将数据库直接存储在本地硬盘上。
这种方式备份速度快，但是容易造成数据丢失。
2. 远程存储将数据库备份存储在远程服务器或云存储上。
这种方式备份安全性高，但是备份速度较慢。
3. 分布式存储将数据库备份分散存储在多个节点上，可以提高备份的可靠性和安全性。
四、选择合适的备份策略1. 完全备份完全备份是指将整个数据库全部备份一次。
这种方式可以保证数据完整性，但是备份时间较长，并且占用空间较大。
2. 增量备份增量备份是指只备份最近一次完全备份之后发生变化的数据。
这种方式可以节省空间和时间，但是恢复时需要先恢复完全备份再逐步恢复增量备份。
3. 差异备份差异备份是指只备份最近一次完全或增量备份之后发生变化的数据。
这种方式比增量备份更快速，但是恢复时需要先恢复完全或增量备份再恢复差异备份。
percona toolkit 使用手册
percona toolkit 使用手册Percona Toolkit 是一个由Percona 公司开发的强大而实用的工具集，它旨在提供一系列的工具和脚本，帮助数据库管理员和开发人员更好地管理和维护 MySQL 数据库系统。
本文将详细介绍 Percona Toolkit 的使用方法和常见功能。
一、Percona Toolkit 简介Percona Toolkit 是一个开源的工具包，包含了多种用于 MySQL 数据库的管理和优化工具。
它提供了丰富的功能，如备份和恢复、查询分析、性能优化、数据同步等，可帮助用户更高效地管理和维护MySQL 数据库系统。
二、安装和配置 Percona Toolkit1. 下载 Percona ToolkitPercona Toolkit 可以从官方网站上下载，下载完成后，解压缩到指定的目录。
2. 配置环境变量将 Percona Toolkit 的路径添加到系统的环境变量中，以便在任何目录下都可以直接使用工具。
三、常用 Percona Toolkit 工具介绍1. pt-archiverpt-archiver 是一个用于归档和清理大表数据的工具，它可以根据条件将旧数据归档到其他表或文件中，以减少主表数据量，提高查询性能。
2. pt-duplicate-key-checkerpt-duplicate-key-checker 可以帮助用户检查数据库中是否存在重复的索引键，它会扫描表数据，找出可能存在的重复键，并给出相应的报告。
3. pt-table-checksumpt-table-checksum 用于检查 MySQL 主从复制的数据一致性，它会比较主库和从库的数据，并报告差异，方便用户及时发现问题并解决。
4. pt-query-digestpt-query-digest 是一个强大的查询分析工具，它可以分析 MySQL 的查询日志，找出慢查询和高负载的查询，帮助用户优化查询性能。
MySQL中的备份与恢复工具推荐
MySQL中的备份与恢复工具推荐MySQL是一款常用的关系型数据库管理系统，备份与恢复是数据库管理中至关重要的工作之一。
本文将介绍一些常用的MySQL备份与恢复工具，让您能够选择适合自己需求的工具。
一、MySQL备份工具推荐1. mysqldumpmysqldump是MySQL自带的备份工具，它能够将数据库中的数据以SQL语句的形式进行备份。
使用mysqldump可以备份整个数据库、特定的表或者特定的数据。
它的使用方法简单，通过命令行可以轻松完成备份工作。
2. XtraBackupXtraBackup是由Percona开发的MySQL备份工具，它能够实现热备份，即在备份过程中数据库仍然可用。
XtraBackup支持增量备份，可以大大缩短备份时间。
此外，XtraBackup还支持压缩备份，可以节省磁盘空间。
3. Zmanda Recovery Manager (ZRM)ZRM是一款功能强大的MySQL备份和恢复管理工具，它提供了图形化界面，使备份和恢复变得更加容易。
ZRM支持全量备份和增量备份，可以定期自动备份数据库，并支持多种备份媒介，如磁盘、磁带等。
此外，ZRM还提供了数据一致性检验和自动恢复功能。
二、MySQL恢复工具推荐1. MySQL Enterprise BackupMySQL Enterprise Backup是由Oracle提供的商业化工具，它可以快速、高效地恢复MySQL数据库。
MySQL Enterprise Backup支持全量备份和增量备份，并且能够快速恢复备份数据。
此外，MySQL Enterprise Backup还提供了灵活的恢复选项，可以按需恢复特定的表或者特定的数据。
2. TwinDB BackupTwinDB Backup是一款开源的MySQL备份工具，它提供了自动备份、增量备份和压缩备份等功能。
TwinDB Backup还支持备份验证和自动恢复功能，确保备份数据的完整性和可用性。
xtrabackup 参数
xtrabackup 参数Xtrabackup 是 Percona 提供的 MySQL 数据库备份工具。
它是一个高性能、低开销的备份工具，并支持局部增量备份。
Xtrabackup 采用一种叫做“流式备份”的方式来备份 MySQL 数据库。
这种方式可以直接备份 InnoDB 存储引擎中的数据文件，而不用停止MySQL 服务来备份数据。
在备份数据时，Xtrabackup 还可以完成一些附加操作，比如自动渐进式备份、对备份数据进行压缩等。
下面，我们来介绍一下 Xtrabackup 的常用参数和使用方法。
备份参数--backup：备份操作的参数。
使用该参数可以备份 MySQL 数据库中的所有数据和日志文件。
--target-dir：备份的目标路径，即备份文件的存放路径。
该参数必须指定。
--incremental：指定增量备份。
增量备份方式可以在原有基础上只备份新增数据，极大地节约备份时间和存储空间。
--incremental-basedir：指定增量备份的基准路径。
该参数必须和 --incremental 参数一起使用，以确定增量备份的起点。
--compress：对备份数据进行压缩。
使用该参数可以减少备份文件的存储空间。
--stream：将备份数据以流的形式输出。
可以将备份数据在网络中传输，也可以通过管道传输数据。
--parallel：指定备份数据时使用的线程数。
该参数可以提高备份速度，但会增加系统负担。
--compact：使用紧凑模式备份。
该模式会将备份文件进行紧凑编码，节约备份空间。
--warm-up-threshold：指定在备份之前需要走过的热身时间。
热身时间用于让数据库缓存数据，提高备份效率。
还有其他一些备份参数，比如 --no-timestamp、--history、--slave-info 等。
这些参数可以帮助你更好地备份 MySQL 数据库，并可以满足不同的备份需求。
还原参数--prepare：准备备份文件进行还原。
MySQL中的数据库备份工具推荐
MySQL中的数据库备份工具推荐一、引言MySQL是一个广泛使用的开源关系型数据库管理系统，它的高性能、易用性和稳定性使其成为了许多应用程序的首选。
然而，由于各种原因，数据库中的数据有时候可能会丢失或损坏。
为了保护数据的安全和完整性，数据库备份是至关重要的。
二、数据库备份的重要性数据库备份是一种重要的数据保护措施，它可以帮助我们在数据丢失或损坏的情况下快速恢复，并减少因此带来的损失和影响。
数据库备份可以用来应对各种突发情况，比如软件故障、硬件故障、人为错误等。
三、MySQL中的备份方法在MySQL中，有多种方法可以进行数据库备份。
下面介绍几种常用的备份方法。
1.物理备份物理备份是将数据库的物理文件直接复制到另一个位置或设备中。
这种备份方法快速简单，可以完整地复制数据库的所有数据和结构。
常见的物理备份方法包括使用文件系统工具（如cp或rsync），以及使用专门的备份工具（如Percona XtraBackup）。
2.逻辑备份逻辑备份是将数据库中的数据导出为文本格式，然后再导入到目标数据库中。
这种备份方法相对慢一些，但它可以通过导入导出过程中的一些操作来进行过滤和转换。
常见的逻辑备份方法包括使用mysqldump工具以及使用数据库复制。
增量备份是指只备份数据库中发生变化的数据部分，以便更加节省时间和空间。
MySQL的二进制日志（binlog）可以用于实现增量备份。
通过将备份日志文件与全量备份文件结合起来，可以完整地还原数据库到任意时间点。
四、备份工具的选择在MySQL中，有许多备份工具可供选择。
下面介绍几个备受推荐的备份工具。
1.XtrabackupXtrabackup是Percona开发的一款开源的MySQL物理备份工具。
它能够在不锁定数据库的情况下进行备份，并支持增量备份。
Xtrabackup还提供了一些高级功能，如并行备份、压缩备份以及复制过滤等，使得备份过程更加高效灵活。
2.mysqldumpmysqldump是MySQL自带的一款逻辑备份工具，它可以导出整个数据库或者指定的表。
mysql pxc 集群原理
mysql pxc 集群原理
MySQL PXC（Percona XtraDB Cluster）是一个基于Galera Replication的开源MySQL集群解决方案。
它提供了多主复制和自动故障转移的功能，确保高可用性和容错性。
PXC集群的工作原理主要包括以下几个方面：
1. 数据同步，PXC集群使用Galera Replication来实现多主复制。
当一个节点上的数据发生变化时，这些变化会被记录成一个事务，并通过Galera Replication协议传播到其他节点。
每个节点都会在本地执行这个事务，从而保持数据的一致性。
2. 数据一致性，PXC集群使用多阶段提交（MSI）来确保数据的一致性。
在一个事务提交之前，所有节点必须先将这个事务应用到本地数据，然后再向其他节点发送确认信息，最终由一个节点来提交这个事务。
这样可以确保在整个集群中的数据保持一致。
3. 自动故障转移，PXC集群可以自动检测到节点的故障，并在必要时重新选择新的主节点。
当一个节点不可用时，集群会自动将原本在该节点上的读写请求转发到其他可用的节点上，从而保证服
务的可用性。
4. Quorum机制，PXC集群使用Quorum机制来确保集群中的大多数节点都是正常的。
只有在大多数节点正常运行时，集群才能继续提供服务，否则集群将停止对外提供服务，以避免数据不一致的情况发生。
总的来说，PXC集群通过Galera Replication和Quorum机制来实现数据同步和故障转移，从而确保了高可用性和容错性。
这些原理使得PXC集群成为一个强大的MySQL集群解决方案，适用于需要高可用性和可扩展性的生产环境。
MySQL死锁案例分：先delete，再insert，导致死锁
MySQL死锁案例分：先delete，再insert，导致死锁⼀、死锁案例MySQL版本：Percona MySQL Server 5.7.19隔离级别：可重复读（RR）业务逻辑：并发下按某个索引字段先delete记录，再insert记录⽐如：1.begin;2.delete from tb where order_id = xxx;3.insert into tb(order_id) values(xxx);4.commit;⼆、MySQL锁基本概念S：共享锁（⾏级锁）X：排他锁（⾏级锁）IS：意向共享锁（表级锁）IX：意向排他锁（表级锁）以上4种锁的兼容性见下表：锁模式兼容性表gap锁与gap锁之间不冲突rec insert intention(插⼊意向锁）与gap锁冲突。
三、模拟复现死锁打开参数，从innodb status获取更多的锁信息。
set GLOBAL innodb_status_output_locks=ON;表结构：1.CREATE TABLE `tb` (2.`order_id` int(11) DEFAULT NULL,3.KEY `idx_order_id` (`order_id`)4.) ENGINE=InnoDB DEFAULT CHARSET=utf8表中数据：1.mysql> select * from tb;2.+----------+3.| order_id |4.+----------+5.| 10 |6.| 20 |7.+----------+8.2 rows in set (0.00 sec)事务执⾏步骤：session1session2beginbegindelete from tb where order_id=15;delete from tb where order_id=15;insert into tb select 15;(等待锁)insert into tb select 15;(死锁)1. 当session1执⾏delete from tb where order_id=15;，由于条件order_id=15的记录不存在，session1 获得2个锁结构，分别是意向排他锁IX（表级锁）、gap锁（⾏级锁），如下：1.---TRANSACTION 1055191443, ACTIVE 20 sec2.2 lock struct(s), heap size 1136, 1 row lock(s)3.MySQL thread id 315642, OS thread handle 139960342456064, query id 150462030 localhost root4.TABLE LOCK table `db`.`tb` trx id 1055191443 lock mode IX5.RECORD LOCKS space id 1337 page no 4 n bits 72 index idx_order_id of table `db`.`tb` trx id 1055191443 lock_mode X locks gap before rec1. 当session2执⾏delete from tb where order_id=15;，同样由于order_id=15的记录不存在，session2 也获得2个锁结构，分别是意向排他锁IX（表级锁）、gap锁（⾏级锁），如下：1.---TRANSACTION 1055191444, ACTIVE 3 sec2.2 lock struct(s), heap size 1136, 1 row lock(s)3.MySQL thread id 315336, OS thread handle 139960562685696, query id 150462412 localhost root4.TABLE LOCK table `db`.`tb` trx id 1055191444 lock mode IX5.RECORD LOCKS space id 1337 page no 4 n bits 72 index idx_order_id of table `db`.`tb` trx id 1055191444 lock_mode X locks gap before rec1. 当session2执⾏insert into tb select 15;， session2 已经获取到IX锁，gap锁，等待 rec insert intention（插⼊意向锁）1.---TRANSACTION 1055191444, ACTIVE 68 sec inserting2.mysql tables in use 1, locked 13.LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 14.MySQL thread id 315336, OS thread handle 139960562685696, query id 150462778 localhost root executing5.insert into tb select 156.------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:7.RECORD LOCKS space id 1337 page no 4 n bits 72 index idx_order_id of table `db`.`tb` trx id 1055191444 lock_mode X locks gap before rec insert intention waiting8.------------------9.TABLE LOCK table `db`.`tb` trx id 1055191444 lock mode IX10.RECORD LOCKS space id 1337 page no 4 n bits 72 index idx_order_id of table `db`.`tb` trx id 1055191444 lock_mode X locks gap before rec11.RECORD LOCKS space id 1337 page no 4 n bits 72 index idx_order_id of table `db`.`tb` trx id 1055191444 lock_mode X locks gap before rec insert intention waiting1. 当session1执⾏insert into tb select 15;，session1 已获取到IX锁，gap锁，等待rec insert intention（插⼊意向锁）， session1,session2 都在等待插⼊意向锁，插⼊意向锁与gap锁冲突，双⽅都没有释放gap锁，⼜都在等待插⼊意向锁，死锁发⽣。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
--前言
上次用了zabbix自带的mysql插件来监控mysql数据库，但是太过简陋了，对于我们dba来说，基本没有啥作用，所以需要做更详细的监控，而percona就有这个详细监控的模版以及脚本，正好拿过来用。
1，需要安装php脚本运行环境
percona监控zabbix的脚本使用php写的，所以需要准备好php运行环境，这里直接用yum
2，加载官方percona模版
去percona官网下载：
看到会生成2个目录，/var/lib/zabbix/percona/scripts是监控脚本目录，/var/lib/zabbix/percona/templates是监控mysql的xml模版目录，然后把/var/lib/zabbix/percona/templates/目录下的模版文件zabbix_agent_template_percona_mysql_server_ht_2.0.9-sver1.1.6_1.xml复制出来，在zabbix 的管理界面import导入进去，但是报如下错误：
Import failed
Details
Invalid XML tag "/zabbix_export/date": "YYYY-MM-DDThh:mm:ssZ" is expected.
经过核查，这个原因是模版错误，是因为percona官方上1.1.6还是zabbix2.0的版本模版，所以需要跟新上来匹配zabbix3.0的模版规范，而且这个zabbix模版还是直接copy的cacti 模版，比较粗糙，用more查看就可以看到里面都是cacti的内容，可见percona官网对zabbix
3，修改配置模版加载成功
在原来的zabbix_agent_template_percona_mysql_server_ht_2.0.9-sver1.1.6_1.xml之上进行修改，改完后就可以import导入进去了，我将修改好的模版文件share下，地址是：/detail/mchdba/9522634
4，添加参数支持
拷贝userparameter_percona_mysql.conf 文件到被监控的mysql服务器上
修改客户端的zabbix_agentd.conf文件,增加Include 把userparameter_percona_mysql.conf 所
5，修改监控脚本
修改vim /var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh脚本，若mysql没有使用默端口3006，则还需要修改如下脚本文件，哥在这里被坑了好久，修改端口号码文件：
修改vim /var/lib/zabbix/percona/scripts/ss_get_mysql_stats.php脚本，这里主要修改用户名密
6，登陆mysql创建监控要用的账号
GRANT SELECT, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO 'zabbixmoniter'@'localho
mkdir /var/lib/zabbix/percona/scripts/
[root@zabbix_serv_121_12 scripts]# scp /var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh
/var/lib/zabbix/percona/scripts/ss_get_mysql_stats.php 192.161.3.62:/usr/local/zabbix/
root@192.161.3.62's password:
get_mysql_stats_wrapper.sh
100% 1251 1.2KB/s 00:00
ss_get_mysql_stats.php
100% 57KB 57.0KB/s 00:00
[root@zabbix_serv_121_12 scripts]#
[root@db_m1_slave_1 zabbix]# ll /var/lib/zabbix/percona/scripts/
total 64
-rwxr-xr-x. 1 zabbix zabbix 1399 May 13 20:56 get_mysql_stats_wrapper.sh
-rwxr-xr-x. 1 zabbix zabbix 58342 May 13 21:06 ss_get_mysql_stats.php
[root@db_m1_slave_1 zabbix]#
7，测试下监控项
在客户端测试下
[root@db_m2_slave2 ~]# /usr/bin/php -q /var/lib/zabbix/percona/scripts/ss_get_mysql_stats.php --host localhost --items gg
gg:13
[root@db_m2_slave2 ~]#
在服务器测试下
[root@zabbix_serv_121_12 ~]# /usr/local/zabbix/bin/zabbix_get -s 192.161.3.73 -p10050 -k "MySQL.Threads-connected"
1
[root@zabbix_serv_121_12 ~]#
[root@zabbix_serv_121_12 ~]# /usr/local/zabbix/bin/zabbix_get -s 192.161.3.73 -p10050 -k "MySQL.Handler-commit"
8777484
[root@zabbix_serv_121_12 ~]#
8，在zabbix管理界面添加percona mysql监控
在hosts里面的templates里面添加percona mysql 的连接，就可以加入percona mysql模版监控了，加完，会看到items增加到262个，graphs增加55个，如022.png所示：
9，然后去监控界面查看监控效果图
比如InnoDB Buffer Pool，如021.png所示：
比如MySQL Transactions Handler，如023.png所示：
比如MySQL Processlist，如024.png所示：
10，mysql从库监控slave配置
先在mysql slave的agent里面需要check下看是否生效：
最好在zabbix管理界面，进入Hosts的mysql从库里面，进入triggers选项栏下面会看到从percona模版加载进来的slave监控项“Slave is stopped on {}”，过几分钟，就会看到slave监控生效了，如下图025.png所示：
参考文章：/1403836/1757326。