By PolarDB-X team
Alibaba Cloud PolarDB for Xscale (PolarDB-X) is a cloud-native high-performance distributed database service independently developed by Alibaba Cloud. PolarDB-X features a shared-nothing system architecture that separates storage and computing resources. The system is composed of five core components.
Architecture of PolarDB-X
As the system's entry point, CN is designed to be stateless, comprising SQL parser, optimizer, and executor modules. It supports distributed routing, computing, dynamic scheduling, distributed transaction coordination using 2PC, and global secondary index maintenance. Additionally, it provides enterprise-level features such as SQL throttling and three-role mode.
The Data Node is responsible for persistently storing row-oriented data and ensuring high reliability and strong consistency based on the Paxos majority protocol. It maintains the visibility of distributed transactions using MVCC.
GMS maintains the global strong consistency of meta-information, including tables, schemas, and statistics. It also maintains security information such as accounts and permissions, and provides a global timestamp distributor called Timestamp Oracle (TSO).
CDC provides incremental subscription that supports MySQL binary log formats and protocols, as well as primary/secondary replication that supports MySQL replication protocols.
Columnar provides persistent Clustered Columnar Index (CCI) and consumes binary logs of distributed transactions. Columnar builds CCI based on the OSS media to meet the requirements of real-time updates. Combined with CN, it provides snapshot-consistent query capabilities for column-oriented storage.
Open source address: https://github.com/polardb/polardbx-sql
Let's look at the open source process of PolarDB-X.
▶ In October 2021, PolarDB-X officially went open source at the Apsara Conference, adopting the open-source kernel engine mode, which included the compute engine, storage engine, log engine, and Kube.
▶ In January 2022, PolarDB-X officially released version 2.0.0, the first version update since its open source, featuring cluster scaling, compatibility with the binary log ecosystem, and support for incremental subscriptions to Maxwell and Debezium, as well as fixing many issues.
▶ In March 2022, PolarDB-X officially released version 2.1.0, which included four core features to improve stability and eco-compatibility, including the Paxos-based three-replica consensus protocol.
▶ In May 2022, PolarDB-X officially released version 2.1.1, which introduced new features for hot and cold data, allowing business tables to be stored in different storage media based on data characteristics, such as storing cold data in Alibaba Cloud Object Storage Service (OSS).
▶ In October 2022, PolarDB-X officially released version 2.2.0, a milestone version that focused on introducing enterprise-level and domestic ARM adaptation, meeting the standards for financial distributed transactional databases, with eight features to comprehensively improve the universal applicability of PolarDB-X distributed databases in finance, communication, and government affairs.
▶ In March 2023, PolarDB-X officially released version 2.2.1, which emphasized production-level key capabilities to improve the ease of use and security for the database production environment, such as fast data import, performance testing and verification, and production deployment suggestions.
▶ In October 2023, PolarDB-X officially released version 2.3.0, focusing on the PolarDB-X Standard Edition (centralized architecture) and providing independent services for PolarDB-X DNs, supporting the multi-replica mode of the Paxos protocol and the Lizard distributed transaction engine, and achieving 100% compatibility with MySQL, corresponding to the PolarDB-X Standard Edition.
▶ In April 2024, PolarDB-X officially released version 2.4.0, focusing on Columnar, which provides persistent CCI. By default, row-oriented tables in PolarDB-X have primary key indexes and secondary indexes. A CCI is an additional column-based secondary index covering all columns of row-oriented storage by default. A table can have both row- and column-oriented data, and combined with vectorized computing on compute nodes, it can accelerate queries in a distributed environment and implement HTAP.
As cloud-native technology continues to gain popularity, new generations of cloud-native data warehouses, represented by Snowflake, and HTAP (Hybrid Transactional and Analytical Processing) database architectures are emerging. It's expected that HTAP with hybrid row-column storage will become a standard capability of databases in the future. Therefore, the design of column-oriented storage in current databases needs to consider low cost, ease of use, and high performance for future development.
PolarDB-X officially released its CCI feature in v2.4. By default, row-oriented tables in PolarDB-X have primary key indexes and secondary indexes. The CCI is an additional column-based secondary index that covers all columns of row-oriented storage by default. A table can have both row- and column-oriented data.
PolarDB-X CCI
Created Syntax
DDL Syntax Created by CCI
● CLUSTERED COLUMNAR: the keyword to specify the type of the added index as CCI
● Index Name: the name of the index to specify the index in the SQL statement
● Sort Key: the sort key of the index (data is stored in order by this column in the index file)
● Index Partitioning Clause: the partitioning algorithm of the index (the same as the syntax of the partitioning clause in CREATE TABLE)
For example:
# Create a table
CREATE TABLE t_order (
`id` bigint(11) NOT NULL AUTO_INCREMENT,
`order_id` varchar(20) DEFAULT NULL,
`buyer_id` varchar(20) DEFAULT NULL,
`seller_id` varchar(20) DEFAULT NULL,
`order_snapshot` longtext DEFAULT NULL,
`order_detail` longtext DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `l_i_order` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 partition by hash(`order_id`) partitions 16;
# Create a CCI
CREATE CLUSTERED COLUMNAR INDEX `cc_i_seller` ON t_order (`seller_id`) partition by hash(`order_id`) partitions 16;● Base Table: "t_order" is a partitioned table that is hashed by the "order_id" column.
● CCI: "cc_i_seller" is sorted by the "seller_id" column and hashed by the "order_id" column.
● Index Definition Clause: CLUSTERED COLUMNAR INDEX cc_i_seller ON t_order (seller_id) partition by hash (order_id) partitions 16.
Data Structure of CCI
CCI is built by columnar engine nodes. The columnar engine nodes use the two-layer model of Delta + Main (an LSM-like structure). By using the marked deletion technology (update is converted into delete mark + insert), the nodes ensure low latency in data synchronization between row- and column-oriented storage and guarantee real-time updates in seconds. Data are written to MemTable in real time. In a cycle of group commit, the data are stored in a local CSV file and appended to the tail of the corresponding CSV file on OSS. This file is called the delta file. The CSV file on the OSS does not exist for a long time. It is converted into the ORC file by the compaction thread from time to time.
Data Forwarding
Test sets: TPC-H 100 GB hardware environment:
| Purpose | Server | Specification |
| Load generator | ecs.hfg7.6xlarge | 24c96g |
| Database machine | ecs.i4.8xlarge * 3 | Storage: 32c256g + 7 TB |
After the import of TPC-H 100 GB of data as normal, execute the following SQL statements to create a CCI:
create clustered columnar index `nation_col_index` on nation(`n_nationkey`) partition by hash(`n_nationkey`) partitions 1;
create clustered columnar index `region_col_index` on region(`r_regionkey`) partition by hash(`r_regionkey`) partitions 1;
create clustered columnar index `customer_col_index` on customer(`c_custkey`) partition by hash(`c_custkey`) partitions 96;
create clustered columnar index `part_col_index` on part(`p_size`) partition by hash(`p_partkey`) partitions 96;
create clustered columnar index `partsupp_col_index` on partsupp(`ps_partkey`) partition by hash(`ps_partkey`) partitions 96;
create clustered columnar index `supplier_col_index` on supplier(`s_suppkey`) partition by hash(`s_suppkey`) partitions 96;
create clustered columnar index `orders_col_index` on orders(`o_orderdate`,`o_orderkey`) partition by hash(`o_orderkey`) partitions 96;
create clustered columnar index `lineitem_col_index` on lineitem(`l_shipdate`,`l_orderkey`) partition by hash(`l_orderkey`) partitions 96;| Scenario | Column-oriented (unit: seconds) | Row-oriented (unit: seconds) | Higher performance |
| tpch-Q1 | 2.98 | 105.95 | 35.5 times |
| select count(*) from lineitem | 0.52 | 19.85 | 38.1 times |
Comparison between the row- and column-oriented effects of TPCH-Q1:
tpch-Q1
Comparison between the row- and column-oriented effects of select count:
count query
Based on the CCI performance white paper, the open source version can refer to: the TPC-H test report [1].
TPC-H 100 GB, a total of 25.76 seconds for 22 queries
The detailed data is as follows:
| Query Statement | Duration (unit: seconds) |
| Q1 | 2.59 |
| Q2 | 0.80 |
| Q3 | 0.82 |
| Q4 | 0.52 |
| Q5 | 1.40 |
| Q6 | 0.13 |
| Q7 | 1.33 |
| Q8 | 1.15 |
| Q9 | 3.39 |
| Q10 | 1.71 |
| Q11 | 0.53 |
| Q12 | 0.38 |
| Q13 | 1.81 |
| Q14 | 0.41 |
| Q15 | 0.46 |
| Q16 | 0.59 |
| Q17 | 0.32 |
| Q18 | 3.10 |
| Q19 | 0.88 |
| Q20 | 0.81 |
| Q21 | 1.84 |
| Q22 | 0.79 |
| Total | 25.76 seconds |
PolarDB-X v2.3 integrates centralized and distributed architectures (the integrated centralized-distributed solution). In October 2023, the centralized architecture was available on both the Alibaba public cloud and PolarDB-X Lite and provided services by using multiple replicas on distributed DNs to support the Paxos-based multi-replica architecture and Lizard transaction system, which can be 100% compatible with MySQL.
The integrated centralized-distributed solution means that PolarDB-X has the scalability of distributed databases and the performance of a standalone database. It can switch between the two types of architecture smoothly. The DNs in PolarDB-X are isolated as centralized databases, which are fully compatible with the standalone databases. If distributed scaling is required due to business expansion, you can upgrade the architecture to a distributed architecture with ease. The corresponding distributed components integrate seamlessly with the original data nodes to facilitate scaling. This eliminates the need to migrate data or modify applications.
Looking back at the official open source of MySQL 8.0, the General Availability (GA) release of version 8.0.11 was officially available in 2018. After about 5 years of continuous evolution, many stability and security-related problems have been fixed and optimized, and version 8.0.3x in 2023 has gradually been steady. PolarDB-X v2.4 has followed the official evolution of MySQL 8.0. The multiple replicas on distributed DNs are fully compatible with MySQL 8.0.32 and quickly inherit many code optimizations of official MySQL:
● Better DDL capabilities, such as Instant DDL (adding columns and removing columns) and Parallel DDL (creating parallel indexes).
● More complete SQL execution capabilities, such as Hash Join and window functions.
PolarDB-X Standard Edition adopts a layered architecture:
● Log layer: uses the majority-based replication protocol of Paxos. Consensus logs of Paxos are compatible with MySQL binary logs. PolarDB-X Standard Edition can provide financial-grade disaster recovery with a recovery point objective of 0 (RPO=0), which guarantees zero data loss in case of a data center failure. This marks a substantial improvement over the MySQL primary/secondary replication protocol (binary log-based async replication or semi-sync replication).
● Storage layer: The in-house Lizard transaction system interfaces with the log layer and can be used to replace the standalone InnoDB transaction system of MySQL. The SCN (System Commit Number) transaction system and GCN (Global Commit Number) transaction system are designed to optimize centralized and distributed transactions. Moreover, based on the SCN standalone transaction system, PolarDB-X Standard Edition provides transaction isolation levels in line with MySQL standards.
● Execution layer: is similar to the server layer of native MySQL. The in-house xRPC server can be used to access PolarDB-X Enterprise Edition to implement distributed queries. PolarDB-X Standard Edition provides this layer with SQL execution capabilities for compatibility with the server layer of native MySQL. It works with the transaction system at the storage layer for data processing.
Hardware Environment:
| Purpose | Server | Specification |
| Load generator | ecs.hfg7.6xlarge | 24c96g |
| Database machine | ecs.i4.8xlarge * 3 | Storage: 32c256g + 7 TB |
TPCC Scenario: Comparing with Open Source MySQL (Deployed with Same Host Hardware)
| Scenario | Concurrency | MySQL 8.0.34 primary/secondary asynchronous replication |
PolarDB-X Standard Edition 8.0.32 Paxos majority | Higher performance |
| TPCC 1000 warehouses | 300 | 170882.38 tpmC | 236036.8 tpmC | ↑38% |
The design of database disaster recovery architecture is the core to ensure the security of critical data and the business continuity of enterprises. With data becoming the critical factor of business operations, any data loss or service disruption can result in significant financial losses. Therefore, when planning a disaster recovery architecture, enterprises need to consider the recovery time objective (RTO) and recovery point objective (RPO) of the data, as well as the associated costs and complexity of the technical implementation.
Active geo-redundancy mainly refers to cross-region disaster recovery capabilities, which can provide read and write capabilities across multiple regions at the same time. In the financial industry, the typical architecture of three data centers across two regions provides geo-disaster recovery. In daily cases, it does not directly provide write traffic. However, with the development of digitalization, more and more industries are facing disaster recovery requirements. For example, industries such as carriers, Internet, and gaming have strong demands for an active geo-redundancy disaster recovery architecture. Currently, common disaster recovery architectures in the database industry include:
● Three data centers in the same city: are generally multiple data centers in a single region, which cannot meet the demands of active multi-region.
● Three data centers across two regions: include the primary region and the geo-backup region for disaster recovery. Traffic is mainly in the primary region, while the remote region is mainly for backup and disaster recovery and the geo-data center does not provide daily active services.
● Five data centers across three regions: are based on the architecture of the multi-region replica of Paxos/Raft.
● Geo-Partitioning: adopts a partitioning architecture based on region attributes and provides read and write capabilities from the geographically nearest database based on user region attributes.
● Global Database: builds a global multi-active architecture. Write operations are performed in the center and each region provides the ability to read for the geographically nearest database.
Let's summarize the advantages and disadvantages of the disaster recovery architectures:
| Architecture | Scope | Minimum data center | Data replica | Advantage and disadvantage |
| Three data centers in the same city | Single data center-level | Three data centers | Sync | Generally common, the average RT of the service increases by about 1 ms. |
| Three data centers across two regions | Data center and region | Three data centers + two regions | Sync | Generally common, the average RT of the service increases by about 1 ms. |
| Five data centers across three regions | Data center and region | Five data centers + three regions | Sync | The construction cost of the data center is relatively high, and the average RT of the service increases by about 5 to 10 ms (the physical distance between regions) |
| Geo-Partitioning | Data center and region | Three data centers + three regions | Sync | The service has an adaptation cost (the region attribute is added to the table partitions), and the average RT of the service increases by about 1 ms. |
| Global Database | Data center and region | Two data centers + two regions | Async | Generally common, read data in the database that is geographically the nearest + write is forwarded. It is suitable for disaster recovery scenarios for geo requirements with more read and less write |
PolarDB-X adopts a multi-replica architecture that uses multiple data replicas such as three or five replicas. To ensure strong consistency between replicas (RPO=0), the architecture uses the Paxos majority consensus replication protocol, which requires that each write operation must be acknowledged by more than half of the nodes. This way, the cluster can continue to provide services without interruption even if a node fails. Paxos can ensure strong consistency by eliminating inconsistency issues among replicas.
Earlier versions before PolarDB-X v2.4 mainly provided the following disaster recovery architectures:
• Single data center (three replicas), which can recover from a single-node failure.
• Three data centers in the same city (three replicas), which can recover from a data center failure.
• Three data centers across two regions (five replicas), which can recover from a city-level failure.
Alibaba Group's Taobao e-commerce business began to build an active geo-redundancy architecture around 2017 and built the multi-active capability of multiple centers across three regions. Therefore, we launched an active geo-redundancy disaster recovery architecture in PolarDB-X v2.4, which refers to the Global Database Network (GDN). PolarDB-X GDN is a network that consists of multiple PolarDB-X clusters that are deployed in multiple regions within a country. It is similar to traditional cross-region disaster recovery for MySQL. (For example, databases in two regions use one-way replication or mutual replication, or multiple regions use mutual replication that consists of a data center and a unit.)
Common business scenarios:
Geo-disaster recovery
By default, the read and write traffic are centralized on the primary instance in the center. The geo-secondary instance serves as a disaster recovery node to read data in the database that is geographically nearest. The PolarDB-X primary instances and secondary instances use mutual replication, and the replication latency is less than 2 seconds, so you can create a geo-secondary instance through the geo-redundancy of the backup set. If the primary instance of the PolarDB-X data center fails in a region, you can manually switch over the disaster recovery, that is, switch the read and write traffic to the secondary instance.
Active geo-redundancy
The business adapts to unitized sharding. Data is read from and written to the database that is geographically nearest based on the granularity of data shards. In this case, both the primary instance and the secondary instance are responsible for read and write traffic. The PolarDB-X primary instances and secondary instances use mutual replication, and the replication latency is less than 2 seconds. If the primary instance of the PolarDB-X data center fails in a region, you can manually switch over the disaster recovery, that is, switch the read and write traffic to the secondary instance.
PolarDB-X v2.4 provides only GDN-based geo-disaster recovery and supports cross-region primary/secondary replication. (Active geo-redundancy will be released in a later version.) GDN is a service that is based on data replication. PolarDB-X provides SQL commands that are highly compatible with MySQL Replica to manage GDN. Simply put, you can configure primary/secondary synchronization in MySQL to quickly configure PolarDB-X GDN.
1. You can run the CHANGE MASTER command compatible with MySQL to build a GDN replication process.
CHANGE MASTER TO option [, option] ... [ channel_option ]
option: {
MASTER_HOST = 'host_name'
| MASTER_USER = 'user_name'
| MASTER_PASSWORD = 'password'
| MASTER_PORT = port_num
| MASTER_LOG_FILE = 'source_log_name'
| MASTER_LOG_POS = source_log_pos
| MASTER_LOG_TIME_SECOND = source_log_time
| SOURCE_HOST_TYPE = {RDS|POLARDBX|MYSQL}
| STREAM_GROUP = 'stream_group_name'
| WRITE_SERVER_ID = write_server_id
| TRIGGER_AUTO_POSITION = {FALSE|TRUE}
| WRITE_TYPE = {SPLIT|SERIAL|TRANSACTION}
| MODE = {INCREMENTAL|IMAGE}
| CONFLICT_STRATEGY = {OVERWRITE|INTERRUPT|IGNORE|DIRECT_OVERWRITE}
| IGNORE_SERVER_IDS = (server_id_list)
}
channel_option:
FOR CHANNEL channel
server_id_list:
[server_id [, server_id] ... ]2. You can run the SHOW SLAVE STATUS command compatible with MySQL to monitor the GDN replication process.
SHOW SLAVE STATUS [ channel_option ]
channel_option:
FOR CHANNEL channel3. You can run the CHANGE REPLICATION FILTER command compatible with MySQL to configure data replication policies.
CHANGE REPLICATION FILTER option [, option] ... [ channel_option ]
option: {
REPLICATE_DO_DB = (do_db_list)
| REPLICATE_IGNORE_DB = (ignore_db_list)
| REPLICATE_DO_TABLE = (do_table_list)
| REPLICATE_IGNORE_TABLE = (ignore_table_list)
| REPLICATE_WILD_DO_TABLE = (wild_do_table_list)
| REPLICATE_WILD_IGNORE_TABLE = (wile_ignore_table_list)
| REPLICATE_SKIP_TSO = 'tso_num'
| REPLICATE_SKIP_UNTIL_TSO = 'tso_num'
| REPLICATE_ENABLE_DDL = {TRUE|FALSE}
}
channel_option:
FOR CHANNEL channel4. You can run the START SLAVE and STOP SLAVE commands compatible with MySQL to start and stop the GDN replication process.
START SLAVE [ channel_option ]
channel_option:
FOR CHANNEL channel
STOP SLAVE [ channel_option ]
channel_option:
FOR CHANNEL channel5. You can run the RESET SLAVE command compatible with MySQL to delete the GDN replication process.
RESET SLAVE ALL [ channel_option ]
channel_option:
FOR CHANNEL channelPolarDB-X is compatible with the MySQL ecosystem, which is easy to start. However, PolarDB-X also needs to develop its customized services. Therefore, in addition to compatibilities with MySQL, PolarDB-X also provides many customized features.
| Feature | Description |
| The one-click creation of multiple GDN replication processes | In the CHANGE MASTER statement, by specifying the STREAM_GROUP option, that is, the stream group name of the PolarDB-X multi-stream binary log cluster, you can create multiple replication processes with one click (depending on the number of binary log streams), which simplifies the user experience. |
| The building of Timestamp-based replication process | In the CHANGE MASTER statement, by specifying the MASTER_LOG_TIME_SECOND option to build a replication process based on a specified time point, which is more flexible compared with the methods of specifying file name and file position. For example, the general process of building a GDN is to prepare the secondary instance through full replication or backup recovery, and then start the incremental replication process. It is obviously easier by specifying the MASTER_LOG_TIME_SECOND. Especially when you connect to PolarDB-X multi-stream binary logs, it is quite complex to specify the file name and file position for each process, but it is quite simple by combining STREAM_GROUP and MASTER_LOG_TIME_SECOND. |
| DML replication policies in multiple modes | In the CHANGE MASTER statement, by specifying the WRITE_TYPE option, you can specify the DML replication policy. The optional policies are as follows: • TRANSACTION: plays back the data as it is strictly based on the transaction unit in the binary log. This method is suitable for scenarios with high requirements for data consistency and transaction integrity. • SERIAL: breaks the transaction unit in the binary log, reorganizes the transaction unit, and performs serial playback. This method is suitable for scenarios where the transaction integrity is not high, but serial replication is still required. • SPLIT: breaks the transaction unit in the binary log and relies on the built-in data conflict detection algorithm for full parallel playback. This method is suitable for scenarios with high throughput and high concurrency. |
| The building of full incremental all-in-one replication | CHANGE MASTER can only create incremental synchronization? In the CHANGE MASTER statement, by specifying the MODE option, you can specify the building mode of the process. • INCREMENTAL: creates an incremental replication process directly. • IMAGE: completes the full replication, and then starts the incremental replication process based on the time point when the full replication starts. |
| Native lightweight mutual replication | In the CHANGE MASTER statement, by combining the WRITE_SERVER_ID and IGNORE_SERVER_IDS options, you can configure a mutual replication process that prevents traffic loopback based on server_id, which is simpler to use without performance degradation compared with the solution that requires additional introduction of transaction tables. |
For the native lightweight mutual replication capability, the example is as follows:
In GDN scenarios, it is critical to ensure consistency between primary and secondary instances and provide convenient data verification. PolarDB-X v2.4 provides not only the comprehensive primary/secondary replication capability but also the native data verification capability so that you can execute relevant SQL commands on secondary instances to implement online data verification. For the time being, PolarDB-X v2.4 only supports the direct verification mode (verification results may have false positives). The snapshot verification capability based on sync point (verification results will not have false positives) will be open source in the next version.
# Enable the verification.
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`}
[MODE='direct' | 'tso']
FOR CHANNEL xxx;
# View the verification progress.
CHECK REPLICA TABLE [`test_db`.`test_tb`] | [`test_db`] SHOW PROGRESS;
# View the different data.
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} SHOW DIFFERENCE;What's more, data consistency not only refers to the consistency between the data contents but also includes the consistency between the schemas. We can say that the data is consistent only when both the contents and schemas are consistent, or, for example, even if one index is lost, it may also cause serious performance problems after the switchover between primary and secondary instances. PolarDB-X GDN supports the replication of various DDL, covering almost all the supported DDL types, especially DDL operations for the specific PolarDB-X schemas, including the synchronization of sequenc and tablegroup.
In addition to data consistency, the other two core metrics for GDN capabilities are RPO and RTO. The lower the replication latency is, the smaller the RPO is, which also indirectly affects the RTO. The PolarDB-X v2.4 provides the RTO minute-level recovery capability with RPO <= 2s. Taking Sysbench and TPCC scenarios as an example, the maximum RPS of a single GDN replication process ranges from 2 w/s to 5 w/s under different network latency conditions (0.1 ms to 20 ms). If the business traffic does not reach the RPS bottleneck of a single replication process, the combination of single-stream binary log and GDN can be used to implement disaster recovery. If the bottleneck is reached, the combination of multi-stream binary log and GDN can be used to improve extensibility. In theory, as long as the network bandwidth does not reach the bottleneck, linear scaling can be implemented regardless of the business traffic size because PolarDB-X GDN has high flexibility and extensibility and high performance based on that.
PolarDB-X supports different forms of quick deployments to meet individual needs.
| Deployment Method | Description | Quick Installation Tool | Dependencies |
| RPM Package | Quick manual deployment with no dependencies on components | RPM download and installation | rpm |
| PXD | Self-developed quick deployment tool to configure quick deployment through YAML files | PXD installation | Python3 and Docker |
| K8S | Quick deployment tool based on Kubernetes operators | Kubernetes installation | Kubernetes and Docker |
Based on the Kubernetes operator architecture, PolarDB-x-operator has officially released version 1.6.0. It provides the deployment and O&M capabilities for PolarDB-X. We recommend you use it in the production environment. For more information, see Introduction to PolarDB-x-operator [2].
The latest version of PolarDB-x-operator 1.6.0 improves the O&M capabilities of centralized and distributed architectures from the perspective of data security, HTAP, and observability. It supports the backup and restoration, transparent data encryption (TDE), read-only columnar (HTAP), one-click diagnostic tool, and CPU core binding for the PolarDB-X Standard Edition. It is also compatible with the kernel of version 8.0.32, which optimizes the stability of the backup and restoration function. For more information, see Release Note [3].
PXD provides quick deployment and O&M capabilities based on the bare physical machine deployment requirements of open-source users. For more information, see Guide to PXD Deployment Mode O&M [4].
The released new version of PXD 0.7 focuses on version upgrades, rebuilding of secondary libraries, and compatibility with the kernel of the new version 8.0.32.
Since version 2.3, in order to facilitate users to quickly experience it, it provides the ability to download and deploy the RPM package, and you can complete the installation of PolarDB-X Standard Edition with one click. For more information, see the link:
PolarDB-X Standard Edition implements multiple replicas based on the Paxos protocol. Based on the Paxos election heartbeat mechanism, MySQL automatically completes node probing and HA switching, which can replace the traditional HA mechanism of MySQL. If PolarDB-X replaces MySQL for production deployment, it needs to solve the adaption problem of HA switchover for the production process, and developers also have their attempts (such as HAProxy or customized proxy). In version 2.4, we have formally integrated an open-source Proxy component.
As a mature MySQL middleware, ProxySQL seamlessly integrates with the MySQL protocol to support PolarDB-X. It offers high availability features such as failover and dynamic routing, providing a reliable and user-friendly proxy option. For further details, please refer to the documentation: Building High-Availability Routing Service for PolarDB-X Standard Edition Using ProxySQL [5].
[1] TPC-H Test Report: https://doc.polardbx.com/zh/performance/distributed/tpch-performance.html (Document in Chinese)
[2] Introduction to PolarDB-X Operator: https://doc.polardbx.com/zh/operator/ (Document in Chinese)
[3] Release Note: https://github.com/polardb/polardbx-operator/releases/tag/v1.6.0
[4] Guide to PXD Deployment Mode O&M: https://doc.polardbx.com/zh/maintance/topics/pxd-maintance/ (Document in Chinese)
[5] Building High-Availability Routing Service for PolarDB-X Standard Edition Using ProxySQL: https://www.alibabacloud.com/blog/building-high-availability-routing-service-for-polardb-x-standard-edition-using-proxysql_601301
Building High-Availability Routing Service for PolarDB-X Standard Edition Using ProxySQL
ApsaraDB - April 10, 2024
ApsaraDB - January 3, 2024
ApsaraDB - June 19, 2024
ApsaraDB - June 4, 2024
Alibaba Clouder - September 27, 2018
Alibaba Clouder - May 20, 2020
PolarDB for MySQL
Alibaba Cloud PolarDB for MySQL is a cloud-native relational database service 100% compatible with MySQL.
Learn More
AnalyticDB for MySQL
AnalyticDB for MySQL is a real-time data warehousing service that can process petabytes of data with high concurrency and low latency.
Learn More
Architecture and Structure Design
Customized infrastructure to ensure high availability, scalability and high-performance
Learn More
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn MoreMore Posts by ApsaraDB
