本文介绍PolarDB MySQL的常见问题和解答。

基本问题

  • Q:什么是PolarDB

    A:PolarDB是一个关系型数据库云服务,目前已在全球十多个地域(Region)的数据中心部署,向用户提供开箱即用的在线数据库服务。PolarDB目前支持3种独立的引擎,分别可以100%兼容MySQL、100%兼容PostgreSQL、高度兼容Oracle语法,存储容量最高可达100TB,用户可以按需购买、按量计费,最低每小时只需要付费1.3元即可体验完整的产品功能。详情请参见什么是PolarDB

  • Q:为什么云原生关系型数据库PolarDB优于传统数据库?

    A:相较于传统数据库,云原生关系型数据库PolarDB支持上百TB级别海量数据存储,提供高可用和高可靠保障、快速弹性升降级、无锁备份等功能,详情请参见产品优势

  • Q:PolarDB是什么时候发布?什么时候开始商用?

    A:2017年9月发布公测,2018年3月开始商用。

  • Q:集群和节点分别指的是什么?

    A:PolarDB采用多节点集群的架构,集群中有一个Writer节点(主节点)和多个Reader节点(只读节点)。单个PolarDB集群支持跨可用区,但不能跨地域,面向集群进行管理和计费。详情请参见PolarDB术语表

  • Q:支持哪些编程语言?

    A:PolarDB支持Java、Python、PHP、Golang、C、C++、.NET、Node.js等编程语言。只要支持原生MySQL的编程语言都可以直接使用PolarDB MySQL,详情请参见MySQL官网

  • Q:支持哪些存储引擎?

    A:PolarDB MySQL全部表均使用InnoDB存储引擎。创建表的时候,PolarDB MySQL会自动将非InnoDB引擎(如 MyISAM、Memory、CSV 等)转换为InnoDB 引擎,因此即使迁移之前的数据表不是InnoDB,也仍然能够正常迁移至PolarDB MySQL

  • Q:是否支持自建Slave实例,是否有推荐的实现方式?

    A:支持。启用Binlog后可以将PolarDB MySQL同步到其他MySQL库,构成Master-Slave架构。为方便后续维护,建议您使用数据传输服务DTS(Data Transmission Service),关于如何使用DTS实现同步,请参见从PolarDB MySQL同步至RDS MySQL

兼容性

  • Q:是否兼容社区版MySQL?

    A:PolarDB MySQL可以100% 兼容社区版MySQL。

  • Q:支持哪些事务隔离级别?

    A:PolarDB MySQL支持READ_UNCOMMITTED、READ_COMMITTED(默认)、REPEATABLE_READ这三种隔离级别,不支持SERIALIZABLE隔离级别。

  • Q:SHOW PROCESSLIST与社区版MySQL是否存在差异?

    A:如果是通过主地址查询,两者没有区别。但如果是通过集群地址查询,略有差异,此时会出现有多条相同Thread ID的记录,分别对应PolarDB MySQL集群中的每一个节点。

  • Q:锁机制和社区版MySQL是否存在差异?

    A:PolarDB MySQL会将DDL中涉及到的Exclusive MDL锁同步到读节点上(同样通过redo日志),并且使读节点持有MDL锁直到DDL操作结束,来阻止读节点上其它用户线程在DDL执行过程中访问表数据。与社区版MySQL不同,PolarDB MySQL的主节点和读节点是基于共享存储的,这会导致主节点在做DDL的时候,读节点可能会查询到DDL过程中的中间数据而出现错误。

  • Q:Binlog格式和MySQL原生格式是否存在差异?

    A:没有差异。

  • Q:是否支持performance schema和sys schema?

    A:支持。

  • Q:表统计信息收集和社区版MySQL是否存在差异?

    A:PolarDB MySQL主节点的表统计信息和社区版MySQL一致。为了保证主节点和只读节点执行计划的一致性,主节点每次更新统计信息时,会同步到只读节点。此外,只读节点还可以通过ANALYZE TABLE操作,主动从磁盘加载最新的统计信息。

  • Q:PolarDB是否支持XA事务,和官方MySQL是否存在差异?

    A: 支持,没有差异。

  • Q:PolarDB是否支持全文索引?
    A:支持。
    说明 目前,用户使用全文索引时,只读节点存在一定的索引缓存数据延迟,建议读写全文索引的操作都使用主地址,以读到最新的数据。
  • Q:是否支持Percona工具集?

    A: 支持,但是建议您使用online DDL。

  • Q:是否支持gh-ost?

    A:支持,但是建议您使用online DDL。

费用

  • Q:PolarDB的费用都包含哪些?

    A:包含存储空间、计算节点、备份(附赠免费额度)、SQL洞察(可选),详情请参见规格与定价

  • Q:收费的存储空间都包含哪些内容?

    A:包含数据库表文件、索引文件、undo日志文件、redo日志文件、binlog文件、slowlog文件及少量的系统文件,详情请参见规格与定价

  • Q:PolarDB的存储包怎么用?

    A:购买的包年包月或按量付费的集群,均可使用存储包抵扣存储费用。例如您有3个存储容量均为40GB的集群(即总容量为120GB),这3个集群可以共享一个100GB的存储包,多出的20GB则按量计费,详情请参见使用存储包

集群访问(读写分离)

  • Q:如何实现PolarDB的读写分离?

    A:只需在应用程序中使用集群地址,即可根据配置的读负载节点实现读写分离,详情请参见自定义集群地址

  • Q:一个PolarDB集群内最多可以支持多少个只读节点?

    A:PolarDB采用分布式集群架构,一个集群包含一个主节点和最多15个只读节点(至少一个,用于保障高可用)。

  • Q:多个只读节点间负载不均衡的原因是什么?

    A:只读节点间负载不均衡的原因有只读节点连接数较少、自定义集群地址分配时未包括某个只读节点等。

  • Q:造成主节点负载高或低的原因是什么?

    A:造成主节点(主库)负载高的原因有直连主地址、主库接受读请求、存在大量的事务请求、主从复制延迟高导致请求被路由到主库、只读节点异常导致读请求被路由到主库等。

    而主节点负载较低的原因可能是主库开启了不接受读选项。

  • Q:怎么降低主节点的负载?
    A: 您可以使用如下几种方式降低主节点负载:
    • 使用集群地址来连接PolarDB集群,详情请参见修改和释放集群地址
    • 如果由于事务较多导致主节点压力大,您可以通过控制台打开事务拆分功能,把事务中的部分查询路由到只读节点,详情请参见事务拆分
    • 如果由于复制延迟导致请求被路由到主库,您可以考虑降低一致性等级(如使用最终一致性),详情请参见一致性级别
    • 主库接受读请求,可能也会导致主库负载高,您可以通过控制台关闭主库接受读功能,减少读请求被路由到主库,详情请参见主库不接受读
  • Q:为什么读不到刚插入的数据?
    A:该问题可能是由于一致性级别的配置导致的,PolarDB的集群地址支持如下几种一致性级别:
    • 最终一致性:不论是同一会话(连接)或不同会话,最终一致性都不保证读能够马上读到刚插入的数据。
    • 会话一致性:一定能够读到同一会话插入之后的读数据。
    • 全局一致性:保证同一会话和不同会话都能够读到最新数据。
    说明 一致性等级越高,性能越差,对主库的压力越大,请谨慎选择。对于大多数应用场景会话一致性能够保证业务正常工作,对于少数有强一致性的需求的语句,可以通过Hint /* FORCE_MASTER */来实现,详情请参见一致性级别
  • Q:如何强制SQL到主节点执行?
    使用集群地址时,在SQL语句前加上/* FORCE_MASTER *//* FORCE_SLAVE */,即可强制指定这条SQL的路由方向,详情请参见HINT语法
    • /* FORCE_MASTER */强制请求被路由到主库。该用法可以用于解决少数一致性要求较高的读请求的场景。
    • /* FORCE_SLAVE */强制请求被路由到从库。该用法可以用于解决少数PolarDB代理由于保证正确性,要求特殊语法被路由到主库的场景(比如存储过程的调用,multistatement的使用等语句默认是会被路由到主库)。
    说明
    • 若您需要通过MySQL官方命令行执行上述Hint语句,请在命令行中加上-c参数,否则该Hint会被MySQL官方命令行过滤导致Hint失效,具体请参见MySQL官方命令行
    • Hint的路由优化级最高,不受一致性级别和事务拆分的约束,使用前请进行评估。
    • Hint语句里不要有改变环境变量的语句,例如/*FORCE_SLAVE*/ set names utf8; 等,这类语句可能导致查询结果非预期。
  • Q:是否可以给不同的业务分配不同的地址?不同地址间是否可以达到隔离的效果?

    A:您可以创建多个自定义地址给不同的业务使用,若底层节点不同则自定义地址间可同时具备隔离的效果,不会互相影响。关于如何创建自定义地址,详情请参见设置集群地址

  • Q:如果有多个只读节点,如何为其中某个只读节点单独创建单节点地址?
    A:仅当集群地址读写模式为只读且集群内拥有三个及以上节点时,才支持创建单节点地址,详细操作步骤请参见设置集群地址
    警告 创建单节点地址后,当此节点故障时,该地址可能会有最多1小时的不可用,请勿用于生产环境。
  • Q:一个集群内最多允许创建多少个单节点地址?

    A:如果您的集群内有3个节点,则只允许为其中1个只读节点创建单节点地址;若集群内有4个节点,则允许为其中2个只读节点创建各自的单节点地址,以此类推。

  • Q:只用了主地址,但是发现只读节点也有负载,是否主地址也支持读写分离?

    A:主地址不支持读写分离,始终只连接到主节点。只读节点有少量QPS是正常现象,与主地址无关。

管理与维护

  • Q:如何在线加字段?

    A:支持原生自带的online DDL、pt-osc和gh-ost等工具,建议您使用自带的online DDL操作。

  • Q:如何在线加索引?

    A:支持原生自带的online DDL、pt-osc和gh-ost等工具,建议您使用自带的online DDL操作。

  • Q:主节点(主)与只读节点(备)是否存在复制延迟?

    A:是,它们之间存在毫秒级延迟。

  • Q:什么情况下会导致复制延迟增大?
    A:出现如下情况时会致复制延迟增大:
    • 主节点写入负载高,产生了过多的redo日志,导致只读节点来不及应用。
    • 只读节点负载过高,抢占了过多原本属于应用redo日志的资源。
    • I/O出现瓶颈,导致读写redo日志过慢。
  • Q:存在复制延迟的情况下,如何保证查询的一致性?

    A:您可以使用集群地址并为其选择合适的一致性级别。目前一致性从高到低分别为全局一致性(强一致性)、会话一致性和最终一致性,详情请参见设置集群地址

  • Q:单节点故障的情况下是否可以保证RPO为0?

    A:可以。

  • Q:升级规格配置(比如从2核8GB升级到4核16GB)后端是怎么实现的?对业务有什么影响?

    A:PolarDB的代理(Proxy)和数据库节点(Node)均需要升级到最新的配置,采用多个节点滚动升级的方式尽量减少对业务的影响。目前每次升级大概需要10~15分钟,对业务的影响时间不超过30秒,期间可能会产生1~3次连接闪断,详情请参见变更配置

  • Q:添加节点要多久?是否会影响业务?
    A:每增加一个节点需要5分钟,对业务无影响。关于如何添加节点,详情请参见增加只读节点
    说明 新增只读节点之后新建的读写分离连接会转发请求到该只读节点。新增只读节点之前建立的读写分离连接不会转发请求到新增的只读节点,需要断开该连接并重新建立连接,例如,重启应用。
  • Q:升级到最新版本(小版本升级)要多久?是否会影响业务?

    A:PolarDB采用多节点滚动升级的方式尽量减少对业务的影响,目前每次升级大概需要10~15分钟,对业务的影响时间不超过30秒,期间可能会产生1~3次连接闪断,详情请参见Revision version升级

  • Q:如何进行故障自动切换?

    A:PolarDB采用双活(Active-Active)的高可用集群架构,可读写的主节点和只读节点之间自动进行故障切换(Failover),系统自动选举新的主节点。PolarDB每个节点都有一个故障切换(Failover)优先级,决定了故障切换时被选举为主节点的概率高低。当多个节点的优先级相同时,则有相同的概率被选举为主节点,详情请参见主备切换

备份与恢复

  • Q:PolarDB采用什么备份方式?

    A:PolarDB采用快照(Snapshot)的方式进行备份,详情请参见备份数据

  • Q:数据库恢复的速度如何?

    A:目前,基于备份集(快照)进行恢复(克隆)的速度是40分钟/TB。如果是恢复到任意时间点,则需要包含应用redo日志的时间,这部分的恢复速度大概是20~70秒/GB,整个恢复时间是这两部分之和。

性能和容量

  • Q:为什么PolarDB MySQL相比RDS MySQL性能提升不明显?
    A:在您对PolarDB MySQL和RDS MySQL进行性能对比前,请了解以下注意事项,以便能获得比较准确、合理的性能对比结果。
    • 使用相同规格配置的PolarDB MySQL和RDS MySQL进行性能对比。
    • 使用相同版本的PolarDB MySQL和RDS MySQL进行性能对比。

      因为不同版本的实现机制不一样,例如MySQL 8.0针对多核数CPU做优化,单独抽象出来Log_writer、log_fluser、log_checkpoint、log_write_notifier等线程,但在CPU核数较少的情况下性能则不如MySQL 5.6或5.7。不推荐使用PolarDB MySQL 5.6和RDS MySQL 5.7或8.0进行对比,因为MySQL 5.6的优化器比较旧,不如新版本。

    • 推荐使用模拟线上压力的场景进行实际性能对比,或者使用sysbench进行对比,这样获得的数据更接近线上实际场景。
    • 在对比读性能的时候,不推荐您使用单条SQL进行比较。

      因为PolarDB是计算存储分离的架构,所以单条语句有网络延迟的影响,导致读性能不如RDS。但是线上数据库的缓存命中率基本都在99%以上,因此只有第一次的读会调用I/O,因此读取性能会降低,后续数据都在缓存池(Buffer Pool)中,并不需要调用I/O,因此性能是一样的。

    • 在对比写性能的时候,同样不推荐您使用单条SQL进行比较,推荐模拟线上环境进行压力测试。

      如果要对比RDS性能,请使用PolarDB(主节点+只读节点)和RDS(主实例+半同步的只读实例)进行对比。这是因为PolarDB的架构在写入数据的时候默认采用Quorum机制,即写入数据时默认写入到三副本里面的大多数(在三个副本中的两个或两个以上写入成功,就认为写操作成功了)。PolarDB已经在存储层面做数据冗余,并保证三副本强同步高可靠,使用RDS MySQL的半同步复制(而不是异步复制)进行对比更合理。

    PolarDB MySQL与RDS MySQL的性能对比结果,请参见与RDS MySQL的对比

  • Q:删除数据库后为什么还是占用很多空间?

    A:这是由于redo日志文件占用了空间,通常在2GB~11GB左右,最多时会占用11GB,其中包括缓冲池中8个redo日志(8G)、正在写的redo日志(1GB)、提前创建的redo日志(1GB)以及最后一个redo日志(1GB)。

    缓冲池内的redo日志文件数量由参数loose_innodb_polar_log_file_max_reuse控制,默认值为8。您可以修改这个参数从而减少日志空间占用量,但在压力大的情况下,性能可能会出现周期性的小幅波动。

    loose_innodb_polar_log_file_max_reuse
    说明 调整参数loose_innodb_polar_log_file_max_reuse后,缓冲池不会立刻被清空,随着DML被执行,缓冲池内的数据量才会慢慢减少。如果需要立即清空,请提交工单联系售后服务。
  • Q:表个数上限是多少?表个数到多少时有可能会引起性能下降?

    A:表个数的上限受文件数量限制,详情请参见使用限制

  • Q:IOPS是怎么限制和隔离的?是否会出现多个PolarDB集群的I/O争抢?

    A:PolarDB集群的每个节点根据规格大小设置IOPS,每个节点之间IOPS独立隔离,互不影响。

  • Q:只读节点的性能变慢是否会影响主节点?

    A:只读节点的负载过高、复制延迟增高时,可能会少量增加主节点的内存消耗。

  • Q:打开Binlog之后,对性能有什么影响?

    A:开启Binlog不会影响查询(SELECT)性能,只会影响写入更新(INSERT/UPDATE/DELETE)性能。一般情况下,在读写均衡的数据库中,开启Binlog后对性能影响不超过10%。

  • Q:打开SQL洞察(全量SQL日志审计),对性能有什么影响?

    A:无影响。

  • Q:PolarDB使用了什么高速网络协议?

    A:PolarDB的数据库计算节点和存储节点之间,以及存储数据多副本之间,都使用了双25Gbps RDMA技术,提供低延迟、高吞吐的强劲I/O性能。

  • Q:PolarDB外网连接的带宽上限是多少?

    A:PolarDB外网连接的带宽上限为10Gbit/s。

  • Q:重启节点需要的时间很长怎么办?
    A:当您的集群中存在的文件数量越多,节点重启需要的时间会越长。此时您可以通过修改innodb_fast_startup参数值为ON来加速重启,关于如何修改参数,请参见设置集群参数
    说明PolarDB MySQL 8.0集群支持配置该参数。

大表问题

  • Q:对比传统本地盘的数据库,PolarDB MySQL中的大表存储有什么优势?

    A:PolarDB MySQL中的一张表,物理上会被拆分到N台存储服务器上存储,因此对一张表的I/O会被分摊到多块存储磁盘中,I/O读取的整体吞吐性能(而不是I/O延迟)要远优于集中式的本地盘数据库。

  • Q:大表如何优化?

    A:推荐使用分区表。

  • Q:哪种情况下适合使用分区表?

    A:需要通过裁剪大表来控制查询访问的数据量并且希望该裁剪对业务代码透明(无需修改业务代码)的场景下,适合使用分区表。例如您可以通过使用分区表来定期清理业务历史数据(如删除最早的一个月份分区并新建下个月份分区,实现只保留最近6个月份数据的效果)。

稳定性

  • Q:是否可以对高并发下的PHP短连接进行优化?

    A:可以。在集群地址中,可以通过开启会话级连接池进行优化,详情请参见设置集群地址

  • Q:如何规避个别执行效率低下的SQL拖垮整个数据库?

    A:如果您的PolarDB MySQL集群是5.6或8.0版本,您可以使用语句并发控制Statement Concurrency Control特性来实现针对指定语句的限流。

  • Q:PolarDB是否支持空闲会话超时?

    A:支持。您可以通过修改wait_timeout参数来自定义空闲会话的超时时间,具体操作步骤请参见设置集群参数

  • Q:如何发现慢SQL?
    A:您可以通过如下两种方式发现慢SQL:
    • 直接在控制台上查询慢SQL,详情请参见慢SQL
    • 连接数据库集群后执行show processlist;找出执行时间过长的SQL,关于如何连接数据库集群,请参见连接数据库集群发现慢SQL
  • Q:如何终止慢SQL?
    A:发现慢SQL后,您可以先查看慢SQL的ID,然后执行kill <Id>终止慢SQL。终止慢SQL