What's new in Pika v3.5.3 (英文版本)
As Redis announces the adoption of dual protocols to maintain its commercial interests, the PikiwiDB (Pika) community is pleased to announce the release of the v3.5.3 stable version for production use today.
The v3.5.3 version addresses historical bugs and introduces a multitude of new features. These features primarily include Pika's support for ACL, the removal of residual Slot code from the Sharing mode, separation of fast and slow commands, Redis Stream support, large key analysis tools, and Pika's distributed cluster support for fully automated failover, among others. Additionally, we have enriched the automation test cases in version 3.5.3 to enhance the stability and robustness of the Pika service, providing users with a more efficient and stable experience. This article will mainly elaborate on the significant features, bug fixes, and performance improvements in this update.
Before diving into the main release content of version 3.5.3, please note the following statements:
- Due to trademark issues, the Pika project has been renamed to PikiwiDB. In this article, we will use PikiwiDB (Pika) to refer to the project at https://github.com/OpenAtomFoundation/pika.
- We have created a new project https://github.com/OpenAtomFoundation/pikiwidb, which is a large-capacity KV database compatible with the Redis protocol and based on the Raft protocol. It is mainly designed for scenarios requiring strong consistency, such as storing metadata at a scale of about 10TiB. PikiwiDB will be used to refer to this project specifically.
1 Major Improvements
1.1 PikiwiDB (Pika) Supports ACL
PikiwiDB (Pika) 3.5.3 now fully supports Redis ACL, laying a solid foundation for future multi-tenant support in cloud-native Pika clusters. Before 3.5.3, Pika already supported Redis user authentication methods such as auth/userpass/requirepass, as well as its own command blacklist mode configured through userblacklist in pika.conf. This update maintains backward compatibility and supports these existing methods.
Moreover, we have integrated all Redis ACL TCL test suites into PikiwiDB (Pika)'s test suite to ensure that PikiwiDB (Pika)'s ACL implementation is fully compatible with Redis ACL.
Key PRs:
- PikiwiDB (Pika) Supports ACL
- Fixes ACL User Authentication Issues
- ACL Backward Compatibility with Userblacklist
- Adds Redis ACL Test Suites
1.2 Hybrid Storage Model Supports Bitmap
In a single-node environment, it is impossible to simultaneously optimize PikiwiDB (Pika)'s read/write/compaction, which is known as the "impossible triangle." In version v3.5.2, we supported hybrid storage consisting of cached Redis and RocksDB, which supported five data structures: string/list/set/zset/hashtable. In this release, we have added support for bitmap: https://github.com/OpenAtomFoundation/pika/pull/2253
Additionally, we now support dynamic tuning of Redis cache parameters in version 3.5.3: https://github.com/OpenAtomFoundation/pika/pull/2197
1.3 Separation of Fast and Slow Commands
To prevent slow commands from blocking the execution of fast commands, we have implemented the separation of fast and slow commands at both the Codis-Proxy and PikiwiDB (Pika) levels.
https://github.com/OpenAtomFoundation/pika/pull/2162
1.4 Redis Stream
While PikiwiDB (Pika) previously supported Redis pubsub, which only allowed for online message passing, in version 3.5.3, we have added limited support for Redis Stream, similar to a message queue (MQ), to facilitate safer message transmission. To ensure data safety, we have specifically added support for the Stream data type in our underlying engine, BlackWidow.
Key PR:
Please note that Pika Stream currently does not support consumer group consumption and will be available in future updates.
1.5 Cloud-Native Cluster
In PikiwiDB (Pika) 3.5.0, we open-sourced a Pika-Operator that supports deploying a pair of Pika master and slave on K8s. In version 3.5.2, based on Kubeblocks, our Pika-Operator supported deploying a Pika Cluster in the form of Codis on K8s, but it did not support dynamic scaling at the time.
In version 3.5.3, the latest Pika-Operator now supports node scaling at the Codis Group level and data rebalance.
Key PRs:
- PikiwiDB (Pika) Operator Supports Pika Cluster Auto-Scaling
- Optimizes Codis Slot Migration Speed, Supports Dynamic Adjustment of Migration Threads and Speed
- Pika-Operator Supports Namespaces, Allows Deploying Different Clusters in Different Namespaces
- Pika-Operator Supports Monitoring Metric Collection, Automatically Launches Pika-Exporter
1.6 Compaction Improvements
PikiwiDB (Pika)'s underlying disk storage engine, RocksDB, significantly impacts PikiwiDB (Pika)'s read and write performance during compaction, which appears as "spikes" in monitoring systems. Controlling compaction is key to optimizing Pika's read and write performance.
Key PRs for compaction improvements:
- Adds CompactRange Command to Support Compaction of a Specific Range of Keys
- Improves Compaction Speed and Reduces Compaction Time
- Invokes Disable Compaction When Executing Shutdown Command, Enhances Exit Speed
1.7 Automatic Failover
PikiwiDB (Pika) clusters are currently based on Codis. To enhance the usability of PikiwiDB (Pika) Clusters based on Codis, we have made many extensions to Codis.
The original Codis did not support failover within Groups, requiring the use of Redis Sentinel, which increases operational costs. We have implemented auto failover for Groups within Codis Dashboard by drawing on the functionality of sentinel.
Key PR:
1.8 Observability Enhancements
The key component for PikiwiDB (Pika) observability is Pika-Exporter. Although Redis Cache was added to the 3.5.2 version, it lacked monitoring metrics. In version 3.5.3, we have added metrics such as hit rate, hits per second, Redis Cache memory usage, number of Redis Caches, and number of Redis Cache DBs.
Key PRs:
- Pika Exporter Exposes Cache-Related Data Collection Metrics
- PikiwiDB (Pika) Distributed Cluster Codis Proxy Adds Observable Metrics
- Fixes dbsize Calculation Error
- Fixes Inaccurate Network Monitoring Metric Statistics
1.9 Data Consistency
Version 3.5.3 fixes numerous PikiwiDB (Pika) master-slave synchronization issues, ensuring data consistency.
Key PRs:
- Fixes the Logic for Slave Nodes Receiving Exceptional Reply Packets from Masters During Full-Quantity Replication
- Fixes Inconsistency Issues Between Cache and DB Data in Certain Scenarios
- Fixes Data Loss Issues After Full-Quantity Replication Failure
- Adds Data Synchronization Status During Full-Quantity Replication, Clarifying Data Synchronization Progress
- Fixes the Issue of No Proper Response to Slave Synchronization Requests During Master Instance bgsave Execution
- Fixes Data Inconsistency Issues When Applying Binlog on Slave Instances Without Locking the Operated Key
- Fixes Data Inconsistency Issues After Data Migration
1.10 Test Suite Additions
The PikiwiDB (Pika) test suite consists of gtest unit tests, Redis TCL test suites, and Go test suites. In 3.5.3, we have added Codis cluster e2e tests.
Key PRs:
1.11 Toolkit Additions
PikiwiDB (Pika) has always valued the construction of toolkits, and all related tools can be found at https://github.com/OpenAtomFoundation/pika/tree/unstable/tools. In 3.5.3, we have added a new tool:
1.12 Documentation Updates
The PikiwiDB (Pika) documentation mainly consists of wiki documentation. In 3.5.3, we have updated the documentation for the Redis commands supported by Pika.
Documentation link: https://github.com/OpenAtomFoundation/pika/wiki/Pika-Supports-Redis-Interface-and-Content-Situation
2 Release Improvements
In the first chapter, we described the main feature upgrades and improvements of version 3.5.3. Below is a detailed list of the relevant PRs for this release.
2.1 New Features
- Pika Supports ACL
- During Full-Quantity Replication, Pika Slave Nodes Do Not Accept Read Requests
- Removes Residual Slot Code from Sharing Mode, Returns to v3.0, Where One Pika Instance Has Multiple DBs, Each with Only One Blackwidow
- Automatically Recovers Service When Codis Dashboard Coroutine Panics
- Pika Cache Adds New Bitmap Data Type
- Pika Supports Separation of Fast and Slow Commands
- Pika Exporter Exposes Cache-Related Data Collection Metrics
- Pika Keeps Unix Timepoint After Completing Bgsave
- Pika Supports Dynamic Configuration of disable_auto_compations Parameter
- Pika Supports Redis Stream
- Pika Supports Large Key Analysis Tools
- Pika Supports Dynamic Adjustment of Pika Cache Parameters
- Updates Pika Benchmark Tool to Support More Interface Pressure Tests
- Pika Operator Supports Pika Cluster Auto-Scaling
- Adds CompactRange Command to Support Compaction of a Specific Range of Keys
- Improves Compaction Speed and Reduces Compaction Time
- Upgrades RocksDB Version to v8.7.3
- PikiwiDB (Pika) Distributed Cluster Codis Proxy Adds Observable Metrics
- PikiwiDB (Pika) Distributed Cluster Supports Automatic Failover
- Pika Supports Redis rename-command Feature
- Optimizes Codis Slot Migration Speed, Supports Dynamic Adjustment of Migration Threads and Speed
- PikiwiDB (Pika) Supports Dynamic Adjustment of max-conn-rbuf-size Parameter
- Pika-Operator Supports Namespaces, Allows Deploying Different Clusters in Different Namespaces
- Pika-Operator Supports Monitoring Metric Collection, Automatically Launches Pika-Exporter
- ACL Backward Compatibility with Userblacklist
- Enriches Pika TCL Test Suite
- Enriches Pika Gotest Test Suite
2.2 Bug Fixes
- Fixes Issue of Incorrect Deletion of Dump Files During Full-Quantity Replication by Pika Slave Nodes
- Fixes the Logic for Slave Nodes Receiving Exceptional Reply Packets from Masters During Full-Quantity Replication
- Invokes Disable Compaction When Executing Shutdown Command, Enhances Exit Speed
- Fixes Inaccurate Redis Memory Values in Codis-Dashboard
- Optimizes INFO Command Latency, Reduces Frequency of Checking Disk Usage
- Fixes Issue of Rsync Deleting Temporary Files with Incorrect Path, Leading to Failure in Opening RocksDB
- Fixes Issue of Commands Not Specifying DB Name, Leading to Coredump of Some Commands
- Uses info replication Command in Codis Dashboard Instead of info Command to Query Master IP, Reducing Performance Impact on Pika
- Fixes Inconsistency Issues Between Cache and DB Data in Certain Scenarios
- Fixes Issue of Segmentation Fault When Dump Directory is Empty
- Fixes Issue of Certain Commands' Cache Not Taking Effect Due to Incorrect Flag Calculation
- Fixes Issue of Slave Instances Being Inaccessible Due to Deadlock After Master Instance flushdb in Master-Slave Replication Mode
- Fixes Issue of Commands Not Judging the Return Value of RocksDB
- Standardizes Function Return Values and Initial Values
- Fixes Inaccurate Network Monitoring Metric Statistics
- Fixes Issue of Abnormal Parameters When Loading Configuration File
- Fixes 100% CPU Usage Issue in Codis Dashboard
- Fixes Issue of Abnormal Display of Pika Master-Slave Roles in Codis Front End
- Fixes Data Inconsistency Issues After Data Migration
- Fixes Issue of Inaccurate Display in Codis-dashboard After Scaling or Pod Start/Stop
- Fixes Issue of Repeated Locking at the DB Level
- Fixes Issue of Data Loss After Full-Quantity Replication Failure
- Fixes Issue of No Proper Response to Slave Synchronization Requests During Master Instance bgsave Execution
- Adds Data Synchronization Status During Full-Quantity Replication, Clarifying Data Synchronization Progress
- Fixes Issue of No Locking of Operated Key When Applying Binlog on Slave Instances, Leading to Data Inconsistency
- Fixes Issue of Master Instance Coredump During Codis Slot Migration
- Fixes Issue of Deleting Dump Files in Use During Master-Slave Replication
- Fixes Issue of Rsync Response Errors from Slave Instances During Master-Slave Replication
2.3 Release Tag
PikiwiDB (Pika) v3.5.3 Release Tag
3 Community
If you have any questions, feel free to join our community discussion group. The PikiwiDB (Pika) open-source community appreciates your support and help.
- telegram https://t.me/+gMlTzNacOF1iMTM1
- WeChat Assistant "PikiwiDB"