Personal blog of Yzmir Ramirez

I am a big fan of Percona Monitoring and Management (PMM) and am happy to report that setting up Percona Platform is as easy to set up and offers a lot of value. Percona Platform reached GA status recently and I think you will find it a handy addition to your infrastructure.

What is Percona Platform?

Percona Platform brings together enterprise-level distributions of MySQL, PostgreSQL, and MongoDB plus it includes a range of open source tools for data backup, availability, and management. The core is PMM which provides database management, monitoring, and automated insights, making it easier to manage database deployments. The number of sites with more than 100 separate databases has grown rapidly in the past few years.  Being able to have command and control of that many instances from a CLI has become impossible. Businesses need to move faster in increasingly complex environments which puts ever-increasing pressure on database administrators, developers, and everyone involved in database operations. The spiraling levels of demand make it harder to support, manage, and correct issues in database environments.

What Percona Platform provides is a unified view of the health of your entire database environment to quickly visually identify and remediate issues.  Developers can now self-service many of their database demands quickly and efficiently so they can easily provision and manage databases on a self-service basis across test and production instances. So you spend fewer resources and time on the management of database complexity.

The two keys to Percona Platform are Query Analytics (QAN), which provides granular insights into database behavior and helps uncover new database performance patterns for in-depth troubleshooting and performance optimization, and Percona Advisors, which are automated insights, created by Percona Experts to identify important issues for remediation such as security vulnerabilities, misconfigurations, performance problems, policy compliance, and database design issues. Automated insights within Percona Monitoring and Management ensure your database performs at its best. The Advisors check for replication inconsistencies, durability issues, password-less users, insecure connections, unstable OS configuration, and search for available performance improvements among other functions. 

Percona Platform is a point of control for your database infrastructure and augments PMM to be even more intelligent when connected to the Percona Platform. By connecting PMM with the Percona Platform, you get more advanced Advisors, centralized user account management, access to support tickets, private Database as a Service, Percona Expertise with the fastest SLAs, and more.

So How Do I Install Percona Platform?

The first step is to install PMM by following the Quick Start Guide. You need version 2.2.7 or later.

Second, You will need a Percona Account.

Third, you will need to connect that account to PMM.

I will assume that you will already have PMM installed.  Did I mention that PMM is free, open source software?

Now you can create a name for your organization.

Now login to your PMM dashboard and select the Settings / Percona Platform.  You will need to get your ‘Public Address’ which the browser can populate the value for you if need be.

The PMM Server ID is automatically generated by PMM.  You will need to provide a name for your server, and you will need a second browser window to login into Percona Platform to get the Percona Platform Access Token (this token has a thirty-minute lifetime, so be quick or regenerate another token).

Go back into PMM, paste the Access Token into the Percona Platform Access Token field, and click Connect.

On the Percona Platform page, you will see your PMM instances. Congratulations, you are using Percona Platform!

Advisor Checks

All checks are hosted on Percona Platform. PMM Server automatically downloads them from here when the Advisors and Telemetry options are enabled in PMM under Configuration > Settings > Advanced Settings. Both options are enabled by default.

Depending on the entitlements available for your Percona Account, the set of advisor checks that PMM can download from Percona Platform differ in terms of complexity and functionality.

If your PMM instance is not connected to Percona Platform, PMM can only download the basic set of Anonymous advisor checks. As soon as you connect your PMM instance to Percona Platform, has access to additional checks, available only for Registered PMM instances.

If you are a Percona customer with a Percona Customer Portal account, you also get access to Paid checks, which offer more advanced database health information. A list is provided below.

Check Name	Description	Tier
MongoDB Active vs Available Connections	Checks the ratio between Active and Available connections.	Registered, Paid
MongoDB Authentication	Warns if MongoDB authentication is disabled.	Anonymous, Registered, Paid
MongoDB Security AuthMech	Warns if MongoDB is not using the default SHA-256 hashing as SCRAM authentication method.	Paid
MongoDB IP Bindings	Warns if MongoDB network binding is not set as recommended.	Anonymous, Registered, Paid
MongoDB CVE Version	Shows an error if MongoDB or Percona Server for MongoDB version is not the latest one with CVE fixes.	Anonymous, Registered, Paid
MongoDB Journal Check	Warns if journal is disabled.	Registered, Paid
MongoDB Localhost Authentication Bypass is Enabled	Warns if MongoDB localhost bypass is enabled.	Anonymous, Registered, Paid
MongoDB Non-Default Log Level	Warns if MongoDB is not using the default log level.	Paid
MongoDB Profiling Level	Warns when the MongoDB profile level is set to collect data for all operations.	Registered, Paid
MongoDB Read Tickets	Warns if MongoDB is using more than 128 read tickets.	Paid
MongoDB Replica Set Topology	Warns if the Replica Set cluster has less than three members.	Registered, Paid
MongoDB Version	Warns if MongoDB or Percona Server for MongoDB version is not the latest one.	Anonymous, Registered, Paid
MongoDB Write Tickets	Warns if MongoDB network is using more than 128 write tickets.	Paid
Check if Binaries are 32-bits	Notifies if version_compatible_machine equals i686.	Anonymous, Registered, Paid
MySQL Automatic User Expired Password	Notifies if version_compatible_machine equals i686.	Registered, Paid
MySQL InnoDB flush method and File Format check	Checks the following settings: innodb_file_format, innodb_file_format_max, innodb_flush_method and innodb_data_file_path	Registered, Paid
MySQL Checks based on values of MySQL configuration variables	Checks the following settings: innodb_file_format,innodb_file_format_max,innodb_flush_method and innodb_data_file_path.	Paid
MySQL Binary Logs checks, Local infile and SQL Mode checks	Warns about non-optimal settings for Binary Log, Local Infile and SQL mode.	Registered, Paid
MySQL Configuration Check	Warns if parameters are not following Percona best practices, for infile, replication threads, and replica checksum.	Paid
MySQL Users With Granted Public Networks Access	Notifies about MySQL accounts allowed to be connected from public networks.	Registered, Paid
MySQL User Check	Runs a high-level check on user setup	Registered, Paid
MySQL Advanced User Check	Runs a detailed check on user setup	Paid
MySQL Security Check	Runs a detailed check on user setup	Paid
MySQL Test Database	This check returns a notice if there is a database with name ‘test’ or ‘test_%’.	Registered, Paid
MySQL Version	Warns if MySQL, Percona Server for MySQL, or MariaDB version is not the latest one.	Anonymous, Registered, Paid
PostgreSQL Archiver is Failing	Verifies if the archiver has failed.	Paid
PostgreSQL Cache Hit Ratio	Checks database hit ratio and complains when this is too low.	Paid
PostgreSQL Configuration Change Requires Restart/Reload	Warns when a configuration was changed and requires a server restart/reload	Registered, Paid
PostgreSQL fsync is Disabled	Shows an error if the fsync configuration is disabled, as this can result in unrecoverable data corruption.	Anonymous, Registered, Paid
PostgreSQL Autovacuum Logging Is Disabled	Shows an error if the fsync configuration is disabled, as this can result in unrecoverable data corruption.	Paid
PostgreSQL Checkpoints Logging Is Disabled	Notifies if the log_checkpoints configuration option is not enabled.	Paid
PostgreSQL Max_connections is too high	Notifies if the max_connections setting is set above 300.	Anonymous, Registered, Paid
PostgreSQL Stale Replication Slot	Warns for stale replication slots since these can lead to WAL file accumulation and DB server outage.	Paid
PostgreSQL Super Role	Notifies if there are users with superuser privileges.	Anonymous, Registered, Paid
PostgreSQL Version Check	Warns if the PostgreSQL minor or major versions are not the latest, and shows an error if the major version is 9.4 or older.	Anonymous, Registered, Paid

More Advisors will be added and Perona always welcomes contributions. Check out Percona Platform today!

 

It’s time for the release roundup!

Percona is a leading provider of unbiased open source database solutions that allow organizations to easily, securely, and affordably maintain business agility, minimize risks, and stay competitive.

Our Release Roundups showcase the latest Percona software updates, tools, and features to help you manage and deploy our software. It offers highlights and critical information, as well as links to the full release notes and direct links to the software or service itself to download.

Today’s post includes those releases and updates that have come out since May 16, 2022. Take a look!

 

Percona Distribution for MongoDB 4.4.14-14

On May 25, 2022, we released Percona Distribution for MongoDB 4.4.14-14, a freely available MongoDB database alternative, giving you a single solution that combines enterprise components from the open source community, designed and tested to work together. The aim of Percona Distribution for MongoDB is to enable you to run and operate your MongoDB efficiently with the data being consistently backed up.

This release of Percona Distribution for MongoDB includes improvements and bug fixes, provided by MongoDB and included in Percona Server for MongoDB. The most notable of them are the following:

• Support of the master key rotation for data encrypted using the Keys Management Interoperability Protocol (KMIP) protocol (tech preview feature). This improvement allows users to comply with regulatory standards for data security.
• Fixed the issue where having a large number of split points causes the chunk splitter to not function correctly and huge chunks would not be split without manual intervention. This can be caused when having small shard key ranges and a very high number of documents and where more than 8192 split points would be needed.
• Added the repairShardedCollectionChunksHistory command to restore history fields for some chunks. This aims to fix broken snapshot reads and distributed transactions.
• Fixed incorrect logging of queryHash/planCacheKey for operations that share the same $lookup shape
• Added a new startup parameter that skips verifying the table logging settings on restarting as a replica set node from the standalone mode during the restore. This speeds up the restore process.

Download Percona Distribution for MongoDB 4.4.14-14

 

Percona Distribution for MongoDB 4.2.20

Percona Distribution for MongoDB 4.2.20 was released on May 23, 2022. Bug fixes, provided by MongoDB and included in Percona Server for MongoDB 4.2.20-20 and Percona Distribution for MongoDB 4.2.20 are the following:

• Support of the master key rotation for data encrypted using the Keys Management Interoperability Protocol (KMIP) protocol (tech preview feature). This improvement allows users to comply with regulatory standards for data security.
• Abort the WiredTiger transaction after releasing Client lock to avoid deadlocks.
• Check if the host has cgroups v2 enabled and read the memory limits according to that.
• Return the shutdown error as the top-level error when batch writing command fails due to mongos shutdown.
• Fixed the double free state for the DocumentSource::optimizeAt() pipeline by making sure all pointers are in place before disposing of the pipeline prefix.

Download Percona Distribution for MongoDB 4.2.20

 

Percona Server for MongoDB 4.4.14-14

On May 25, 2022, Percona Server for MongoDB 4.4.14-14  was released. It is an enhanced, source-available, and highly-scalable database that is a fully-compatible, drop-in replacement for MongoDB 4.4.14 Community Edition. It supports MongoDB 4.4.14 protocols and drivers. A release highlight is that it now supports the master key rotation for data encrypted using the Keys Management Interoperability Protocol (KMIP) protocol (tech preview feature). This improvement allows users to comply with regulatory standards for data security.

Download Percona Server for MongoDB 4.4.14-14

 

Percona Server for MongoDB 4.2.20-20

May 23, 2022, saw the release of Percona Server for MongoDB 4.2.20-20. Improvements and bug fixes introduced by MongoDB and included in Percona Server for MongoDB are the following:

• SERVER-64983 – Abort the WiredTiger transaction after releasing Client lock to avoid deadlocks
• SERVER-60412 – Check if the host has cgroups v2 enabled and read the memory limits according to that.
• SERVER-64642 – Return the shutdown error as the top-level error when batch writing command fails due to mongos shutdown.
• SERVER-59435 – Fixed the double free state for the DocumentSource::optimizeAt() pipeline by making sure all pointers are in place before disposing of the pipeline prefix

Download Percona Server for MongoDB 4.2.20-20

 

Percona XtraDB Cluster 5.7.37-31.57

On May 18, 2022, Percona XtraDB Cluster 5.7.37-31.57 was released. It supports critical business applications in your public, private, or hybrid cloud environment. Our free, open source, enterprise-grade solution includes the high availability and security features your business requires to meet your customer expectations and business goals.

The following lists a number of the notable updates and fixes for MySQL 5.7.37, provided by Oracle, and included in Percona Server for MySQL:

• The performance on debug builds has been improved by optimizing the buf_validate() function in the InnoDB sources.
• Fix for when a query using an index that differs from the primary key of the partitioned table results in excessive CPU load.
• Enabling PAD_CHAR_TO_FULL_LENGTH SQL mode on a replica server added trailing spaces to a replication channel’s name in the replication metadata repository tables. Attempts to identify the channel using the padded name caused errors. The SQL mode is disabled when reading from those tables.

Find the complete list of bug fixes and changes in MySQL 5.7.37 Release Notes.

Download Percona XtraDB Cluster 5.7.37-31.57

 

Percona XtraBackup 8.0.28-21

Percona XtraBackup 8.0.28-21 was released on May 25, 2022. It enables MySQL backups without blocking user queries. Percona XtraBackup is ideal for companies with large data sets and mission-critical applications that cannot tolerate long periods of downtime. Offered free as an open source solution, Percona XtraBackup drives down backup costs while providing unique features for MySQL backups. Percona XtraBackup adds support for the Amazon Key Management Service (KMS) component.

Download Percona XtraBackup 8.0.28-21

 

That’s it for this roundup, and be sure to follow us on Twitter to stay up-to-date on the most recent releases! Percona is a leader in providing best-of-breed enterprise-class support, consulting, managed services, training, and software for MySQL, MongoDB, PostgreSQL, MariaDB, and other open source databases in on-premises and cloud environments.

Today we are talking about Storage Entities with Martin Anderson-clutz.

www.talkingDrupal.com/349

Topics

• Miller
• TD site update
• Storage Entities
• Inspiration
• Benefit of new entity type
• Comparison to custom entity
• Lightweight by design
• Roadmap
• Use cases
• Revisions
• Inline entity form
• Core candidacy
• Naming modules
• Getting Started

Resources

• https://github.com/johnkerl/miller
• https://www.drupal.org/project/storage
• https://www.drupal.org/project/inline_entity_form
• https://www.drupal.org/project/tasks
• https://www.drupal.org/project/quick_links
• https://www.drupal.org/project/autogrid
• https://www.drupal.org/project/auto_entitylabel
• https://www.drupal.org/project/microcontent
• https://www.drupal.org/project/ideas/issues/607396
• https://www.drupal.org/project/content_moderation_link

Guests

Martin Anderson-Clutz – @mandclu

Hosts

Nic Laflin – www.nLighteneddevelopment.com @nicxvan John Picozzi – www.epam.com @johnpicozzi Mike Herchel – herchel.com – @mikeherchel

MOTW

Preview Link Provides a preview link that is tokenised, and therefore bypasses access control to allow any user to view the latest revision of an entity.

Are you looking for a fun, boho-inspired addition to your child’s room? Then macrame baby swing is a must-have. It’s perfect for those lazy summer days when you want to relax and watch your little one play.

Macrame baby swings are becoming increasingly popular, and it’s no wonder why. They add a touch of whimsy and charm to any room. Macrame baby swings are similar to hammocks, but they’re smaller and have a more delicate design.

Whether you want to buy a macrame baby swing or do it yourself, we’ve got you covered. This article will show you how to make your own macrame baby swing and where to buy one if you’re not up for the DIY challenge.

What Is Macrame?

Macrame is a form of textile-making that uses knotting techniques to create intricate patterns. It first became popular in the 1970s but has seen a resurgence in recent years due to the bohemian/boho-chic trend.

While macrame can be used to create a wide variety of items, It’s often used to make wall hangings, plant hangers, and other home decor items.

Is A Macrame Baby Swing Safe?

Yes, macrame baby swings are safe. They’re made out of lightweight materials and have sturdy construction. However, it’s important to make sure that the swing is hung securely and that there’s nothing nearby that your child could bump into while playing.

A lot of time macrame baby swings come with wooden elements like a bar or hoop. These can add extra stability and security to the swing.

Where To Put The Macrame Baby Swing?

Macrame baby swings can be hung indoors or outdoors. They look great in a child’s bedroom, playroom, or even living room. If you’re planning on using it outdoors, choose a shady spot out of the way of any potential hazards.

As with any piece of baby gear, there are some safety considerations to keep in mind when using a macrame baby swing.

1. Always use the swing indoors or in a shady, well-ventilated area outdoors. The swing should never be left in direct sunlight.
2. Make sure the swing is on a level surface before letting your child use it. The last thing you want is for the swing to tip over while your child is in it.
3. Never leave your child unattended in the swing. Always stay within arms’ reach if your child needs help getting out or falls asleep in the swing.
4. Inspect the swing regularly for any signs of wear and tear. If you see any fraying or damage to the rope, discontinue the use of the swing and replace the damaged parts.

By following these simple safety tips, you can ensure your child has a safe and enjoyable experience in their macrame baby swing.

Best Ready-To-Buy Macrame Baby Swings

If you’re not up for the challenge of making your own macrame baby swing, then there are plenty of options available to purchase. Here are some of our favorites!

S.N.HANDICRAFTS Handmade Macrame Baby Swing

This macrame baby swing is handmade in India using 100% cotton rope. It’s durable and perfect for indoor or outdoor use. Perfect for toddlers up to 50 lbs.

Mass Lumber Macrame Baby Swing Outdoor Seat with Belt

This macrame baby swing is made out of durable materials. It has a safety belt to keep your child secure and can hold up to 110 lbs. Perfect for use outdoors.

N\A Wooden Macrame Baby Swing

A high-quality, handmade cotton Macrame baby swing composed of solid wood and knitted by hand, offering excellent safety and quality. The baby swing includes a 39-inch chain and a non-slip children’s seat cushion, which is both comfortable and supportive for your little one.

The swing may be raised or lowered as required to ensure that the infant is more comfortable. The swing can bear up to 80 pounds, and it is designed for children aged 1-5.

Bean Sprout Baby Collection – Baby Hammock Swing Chair

The Bean Sprout Baby Hammock Swing Chair is the perfect place for your little one to relax. It is a premium quality macrame baby swing made of 100% cotton. It is soft, comfortable, and safe for your baby.

Choosing A Macrame Baby Swing

When choosing a macrame baby swing, there are a few things to keep in mind. First, consider the size of the swing. It should be big enough for your baby to comfortably sit or lie down in but not so large that it takes up too much space in the room.

Second, think about the design. There are many different macrame patterns to choose from. Some are more intricate than others. Consider the overall style of your home and choose a swing that fits in with the rest of your decor.

Last, think about functionality. Some swings come with additional features like a wooden bar or hoop. These can add stability and security to the swing. Others come with removable cushions for added comfort. Choose the features that are most important to you and your family.

How To Make Macrame Baby Swing Yourself

Making your own macrame baby swing is excellent if you’re feeling crafty and up for the challenge. You will save money, but you’ll also get to choose the perfect design and color scheme for your home.

The Internet is full of different tutorials on making a macrame baby swing. We recommend you check out this step-by-step guide:

What Do You Need To Make A Macrame Baby Swing?

• Macrame cord
• Wooden dowel or hoop
• Wooden base
• Scissors
• Tape measure
• Pencil or pen
• Paper clips

Choosing the suitable macrame cord/rope is crucial in making your own macrame baby swing. The cord should be strong enough to support your child’s weight but also soft and comfortable to the touch.

We recommend using a 3/8-inch (9mm) cotton rope. This size is strong enough to support most babies and toddlers, but it’s also soft and gentle on the skin.

Other popular macrame cords are made of jute or hemp. These materials are also strong and durable, but they’re not as soft as cotton. If you choose to use one of these materials, add a cushion or padding to the swing, so your child is comfortable.

When searching for a macrame baby swing pattern or tutorial, double-check a list of supplies needed. Some designs call for special tools or equipment that you may not have around the house.

We also recommend reading through the entire pattern before starting. This will help you understand the steps involved and ensure you have everything you need.

How Much Macrame Cord Do I Need For A Swing?

The amount of cord you need will depend on the size of the swing and the design you choose.
Most macrame baby swing patterns call for between 50 and 100 feet (15 to 30 meters) of macrame cord.

We recommend purchasing at least 200 feet (60 meters) of cord to be safe. This will give you enough to make a baby swing and allow some mistakes along the way. You can always use the extra cord for another project or donate it to a local craft store.

What Size Rope Is Best For A Baby Swing?

The most popular macrame cord size for a baby swing is 3/8-inch (9mm). This size is strong enough to support most babies and toddlers, but it can vary depending on a particular project.

Why Make A Macrame Baby Swing?

A macrame baby swing is a beautiful and unique addition to your child’s nursery or playroom. Not only is it eye-catching, but it’s also sturdy and functional.

As your child grows, they’ll be able to enjoy the swing as a fun place to play or relax. And when they’re no longer using it, you can easily repurpose it into a wall hanging or other home decor item.

If you decide to make a macrame baby swing yourself, it’s a great way to add a personal touch to your child’s room. Plus, there is something very satisfying about creating something beautiful with your own two hands. Your baby will be able to enjoy the swing for years to come, and it will always hold sentimental value.

The post Macrame Baby Swing – A Boho-Inspired Addition To Your Child’s Room appeared first on Comfy Bummy.

Percona Backup for MongoDB (PBM) is a backup utility custom-built by Percona to help solve the needs of customers and users who don’t want to pay for proprietary software like MongoDB Enterprise and Ops Manager but want a fully-supported open-source backup tool that can perform cluster-wide consistent backups in MongoDB.

Version 1.7.0 of PBM was released in April 2022 and comes with a technical preview of physical backup functionality. This functionality enables users to benefit from the reduced recovery time. 

With logical backups, you extract the data from the database and store it in some binary or text format, and for recovery, you write all this data back to the database. For huge data sets, it is a time-consuming operation and might take hours and days. Physical backups take all your files which belong to the database from the disk itself, and recovery is just putting these files back. Such recovery is much faster as it does not depend on the database performance at all.

In this blog post, you will learn about the architecture of the physical backups feature in PBM, see how fast it is compared to logical backups, and try it out yourself.

Tech Peek

Architecture Review

In general, physical backup means a copy of a database’s physical files. In the case of Percona Server for MongoDB (PSMDB) these are WiredTiger

*.wt

  Btree, config, metadata, and journal files you can usually find in

/data/db

.  The trick is to copy all those files without stopping the cluster and interrupting running operations. And to be sure that data in files is consistent and no data will be changed during copying. Another challenge is to achieve consistency in a sharded cluster. In other words, how to be sure that we are gonna be able to restore data to the same cluster time across all shards.

PBM’s physical backups are based on the backupCursors feature of PSMDB (PSMDB). This implies that to use this feature, you should use Percona Server for MongoDB.

Backup

On each replica set, PBM uses

$backupCursor

to retrieve a list of files that need to be copied to achieve backup. Having that list next step is to ensure cluster-wide consistency. For that, each replica set posts a cluster time of the latest observed operation. The backup leader picks the most recent one. This will be the common backup timestamp (recovery timestamp) saved as the

last_write_ts

in the backup metadata. After agreeing on the backup time, the

pbm-agent

on each cluster opens a

$backupCursorExtend

. The cursor will return its result only after the node reaches the given timestamp. Thus the returned list of logs (journals) will contain the “common backup timestamp”. At that point, we have a list of all files that have to be in the backup. So each node copies them to the storage, saves metadata, closes cursors, and calls it a backup. Here is a blog post explaining Backup Cursors in great detail.

Of course, PBM does a lot more behind the scenes starting from electing appropriate nodes for the backup, coordinating operations across the cluster, logging, error handling, and many more. But all these subjects are for other posts.

Backup’s Recovery Timestamp

Restoring any backup PBM returns the cluster to some particular point in time. Here we’re talking about the time, not in terms of wall time but MongoDB’s cluster-wide logical clock. So the point that point-in-time is consistent across all nodes and replica sets in a cluster. In the case of logical or physical backup, that time is reflected in the

complete

section of

pbm list

  of

pbm status

  outputs. E.g.:

    2022-04-19T15:36:14Z 22.29GB <physical> [complete: 2022-04-19T15:36:16]
    2022-04-19T14:48:40Z 10.03GB <logical> [complete: 2022-04-19T14:58:38]

This time is not the time when a backup has finished, but the time at which cluster state was captured (hence the time the cluster will be returned to after the restore). In PBM’s logical backups, the recovery timestamp tends to be closer to the backup finish. To define it, PBM has to wait until the snapshot on all replica sets finishes. And then it starts oplog capturing from the backup start up to that time. Doing physical backups, PBM would pick a recovery timestamp right after a backup start. Holding the backup cursor open guarantees the checkpoint data won’t change during the backup, and PBM can define complete-time right ahead.

Restore

There are a few considerations for restoration.

First of all, files in the backup may contain operations beyond the target time (

commonBackupTimestamp

). To deal with that, PBM uses a special function of the replication subsystem’s startup process to set the limit of the oplog being restored. It’s done by setting the

oplogTruncateAfterPoint

value in the local DB’s

replset.oplogTruncateAfterPoint

 collection.

Along with the

oplogTruncateAfterPoint

 database needs some other changes and clean-up before start. This requires a series of restarts of PSMDB in a standalone mode.

Which in turn brings some hassle to the PBM operation. To communicate and coordinate its work across all agents, PBM relies on PSMDB itself. But once a cluster is taken down, PBM has to switch to communication via storage. Also, during standalone runs, PBM is unable to store its logs in the database. Hence, at some point during restore,

pbm-agent

logs are being available only in agents’ stderr. And

pbm logs

 won’t have access to them. We’re planning to solve this problem by the physical backups GA.

Also, we had to decide on the restore strategy in a replica set. One way is to restore one node, then delete all data on the rest and let the PSMDB replication do the job. Although it’s a bit easier, it means until InitialSync finishes, the cluster will be of little use. Besides, logical replication at this stage almost neglects all the speed benefits (later on that) the physical restore brings to the table. So we went with the restoration of each node in a replica set. And making sure after the cluster starts, no node will spot any difference and won’t start ReSync.

As with the PBM’s logical backups, the physical once currently can be restored to the cluster with the same topology, meaning replica set names in the backup and the target cluster should match. Although it won’t be an issue for logical backups starting from the next PBM version. And later this feature will be extended to the physical backups as well. Along with that, the number of replica sets in the cluster could be more than those in the backup but not vice-versa. Meaning all data in the backup should be restored. 

Performance Review

We used the following setup:

• Cluster: 3-node replica set. Each mongod+pbm-agent on Digital Ocean droplet: 16GB, 8vCPU (CPU optimized).
• Storage: nyc3.digitaloceanspaces.com
• Data: randomly generated, ~1MB documents

In general, a logical backup should be more beneficial on small databases (a few hundred megabytes). Since on such a scale, the extra overhead on top of data that physical files bring still makes a difference. Basically reading/writing only user data during logical backup means less data needs to be transferred over the network. But as the database grows, overhead on logical read(select) and mostly write(insert) became a bottleneck for the logical backups. As for the physical backup, the speed is almost always bounded only by the network bandwidth to/from remote storage. In our tests, restoration time from physical backups has linear dependency on the dataset size, whereas logical restoration time grows non-linearly. The more data you have, the longer it takes to replay all the data and rebuild indexes. For example, for a 600GB dataset physical restore took 5x less time compared to logical. 

But on a small DB size, the difference is neglectable – a couple of minutes. So the main benefit of logical backups lay beyond the performance. It’s flexibility. Logical backups allow partial backup/restore of the database (on the roadmap for PBM). You can choose particular databases and/or collections to work with.  As physical backups work directly with database storage-engine files, they operate in an all-or-nothing frame.

Hands-on

PBM Configuration

In order to start using PBM with PSMDB or MongoDB, install all the necessary packages according to the installation instructions. Please note that starting from version 1.7.0 the user running the

pbm-agent

 process should also have the read/write access to PSMDB data directory for the purpose of performing operations with datafiles during physical backup or restore. 

Considering the design, starting from 1.7.0 the default user for

pbm-agent

is changed from

pbm

to

mongod

. So unless PSMDB runs under a different user than

mongod

, no extra actions are required. Otherwise, please carefully re-check your configuration and provide the necessary permissions to ensure proper PBM functioning.

In addition, keep in mind that for using PBM physical backups, you should run Percona Server for MongoDB starting from versions 4.2.15-16 and 4.4.6-8 and higher – this is where hotBackups and backup cursors were introduced.

Creating a Backup

With the new PBM version, you can specify what type of backup you wish to make: physical or logical. By default when no type is selected, PBM makes a logical backup.

> pbm backup
Starting backup '2022-04-20T11:12:53Z'....
Backup '2022-04-20T11:12:53Z' to remote store 's3://https://storage.googleapis.com/pbm-bucket' has started

> pbm backup -t physical
Starting backup '2022-04-20T12:34:06Z'....
Backup '2022-04-20T12:34:06Z' to remote store 's3://https://storage.googleapis.com/pbm-bucket' has started

> pbm status -s cluster -s backups
Cluster:
========
rs0:
  - rs0/mongo1.perconatest.com:27017: pbm-agent v1.7.0 OK
  - rs0/mongo2.perconatest.com:27017: pbm-agent v1.7.0 OK
  - rs0/mongo3.perconatest.com:27017: pbm-agent v1.7.0 OK
Backups:
========
S3 us-east-1 s3://https://storage.googleapis.com/pbm-bucket
  Snapshots:
    2022-04-20T12:34:06Z 797.38KB <physical> [complete: 2022-04-20T12:34:09]
    2022-04-20T11:12:53Z 13.66KB <logical> [complete: 2022-04-20T11:12:58]

Point-in-Time Recovery

Point-in-Time Recovery is currently supported only for logical backups. It means that a logical backup snapshot is required for pbm-agent to start periodically saving consecutive slices of the oplog. You can still make a physical backup while PITR is enabled, it won’t break or change the oplog saving process. 

The restoration process to the specific point in time will also use a respective logical backup snapshot and oplog slices which will be replayed on top of the backup.

Checking the Logs

During physical backup, PBM logs are available via

pbm logs

command as well as for all other operations. 

> pbm logs -e backup/2022-04-20T12:34:06Z
2022-04-20T12:34:07Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] backup started
2022-04-20T12:34:12Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] uploading files
2022-04-20T12:34:54Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] uploading done
2022-04-20T12:34:56Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] backup finished

As for restore,

pbm logs

command doesn’t provide information about restore from a physical backup. It’s caused by peculiarities of the restore procedure and will be improved in the upcoming PBM versions. However,

pbm-agent

still saves log locally, so it’s possible to check information about restore process on each node: 

> sudo journalctl -u pbm-agent.service | grep restore
pbm-agent[12560]: 2022-04-20T19:37:56.000+0000 I [restore/2022-04-20T12:34:06Z] restore started
.......
pbm-agent[12560]: 2022-04-20T19:38:22.000+0000 I [restore/2022-04-20T12:34:06Z] copying backup data
.......
pbm-agent[12560]: 2022-04-20T19:38:39.000+0000 I [restore/2022-04-20T12:34:06Z] preparing data
.......
pbm-agent[12560]: 2022-04-20T19:39:12.000+0000 I [restore/2022-04-20T12:34:06Z] restore finished <nil>
pbm-agent[12560]: 2022-04-20T19:39:12.000+0000 I [restore/2022-04-20T12:34:06Z] restore finished successfully

Restoring from a Backup

The restore process from a physical backup is similar to a logical one but requires several extra steps after the restore is finished by PBM.

> pbm restore 2022-04-20T12:34:06Z
Starting restore from '2022-04-20T12:34:06Z'.....Restore of the snapshot from '2022-04-20T12:34:06Z' has started. Leader: mongo1.perconatest.com:27017/rs0

After starting the restore process, pbm CLI returns the leader node ID, so it’s possible to track the restore progress by checking logs of the pbm-agent leader. In addition, status is written to the metadata file created on the remote storage. The status file is created in the root of the storage path and has the format

.pbm.restore/<restore_timestamp>.json

. As an option it’s also possible to pass

-w

flag during restore which will block the current shell session and wait for the restore to finish:

> pbm restore 2022-04-20T12:34:06Z -w
Starting restore from '2022-04-20T12:34:06Z'....Started physical restore. Leader: mongo2.perconatest.com:27017/rs0
Waiting to finish...........................Restore successfully finished!

After the restore is complete, it’s required to perform the following steps:

• Restart all

  mongod

  (and

  mongos

   if present) nodes

• Restart all pbm-agents
• Run the following command to resync the backup list with the storage:
  

  $ pbm config --force-resync

Conclusion

MongoDB allows users to store enormous amounts of data. Especially if we talk about sharded clusters, where users are not limited by a single storage volume size limit. Database administrators often have to implement various home-grown solutions to ensure timely backups and restores of such big clusters. The usual approach is a storage-level snapshot. Such solutions do not guarantee data consistency and provide false confidence that data is safe.

Percona Backup for MongoDB with physical backup and restore capabilities enable users to backup and restore data fast and at the same time comes with data-consistency guarantees. 

Physical Backup functionality is in the Technical Preview stage. We encourage you to read more about it in our documentation and try it out. In case you face any issues feel free to contact us on the forum or raise the JIRA issue.

The binary logging format in MySQL has been ROW by default since MySQL 5.7, yet there are still many users sticking with STATEMENT or MIXED formats for various reasons. In some cases, there is just simple hesitation from changing something that has worked for years on legacy applications. But in others, there may be serious blockers, most typically missing primary keys in badly designed schemas, which would lead to serious performance issues on the replicas.

As a Support Engineer, I can still see quite a few customers using STATEMENT or MIXED formats, even if they are already on MySQL 8.0. In many cases this is OK, but recently I had to deal with a pretty nasty case, where not using ROW format was found to cause the replicas to silently lose data updates, without raising any replication errors! Was it some really rare edge use case? Not at all! Let me demonstrate a very simple test case below to illustrate how easy it is to end up in such a bad situation.

— source 

mysql> select @@binlog_format,@@system_time_zone;
+-----------------+--------------------+
| @@binlog_format | @@system_time_zone |
+-----------------+--------------------+
| STATEMENT       | BST                |
+-----------------+--------------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE `test1` (
    ->   `id` int(11) NOT NULL AUTO_INCREMENT,
    ->   `d` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    ->   `a` varchar(30) NOT NULL,
    ->   `name` varchar(25) DEFAULT NULL,
    ->   PRIMARY KEY (`a`),
    ->   UNIQUE KEY `id` (`id`)
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected, 1 warning (0.02 sec)

mysql> insert into test1 values (null,now(),"test1",0);
Query OK, 1 row affected (0.00 sec)

mysql> insert into test1 values (null,now(),"test2",0);
Query OK, 1 row affected (0.01 sec)

mysql> insert into test1 values (null,now(),"test3",0);
Query OK, 1 row affected (0.01 sec)

mysql> select * from test1;
+----+---------------------+-------+------+
| id | d                   | a     | name |
+----+---------------------+-------+------+
|  1 | 2022-05-22 10:13:37 | test1 | 0    |
|  2 | 2022-05-22 10:13:37 | test2 | 0    |
|  3 | 2022-05-22 10:13:38 | test3 | 0    |
+----+---------------------+-------+------+
3 rows in set (0.00 sec)

— replica

mysql> select @@system_time_zone;
+--------------------+
| @@system_time_zone |
+--------------------+
| UTC                |
+--------------------+
1 row in set (0.00 sec)

mysql> select * from db1.test1;
+----+---------------------+-------+------+
| id | d                   | a     | name |
+----+---------------------+-------+------+
|  1 | 2022-05-22 09:13:37 | test1 | 0    |
|  2 | 2022-05-22 09:13:37 | test2 | 0    |
|  3 | 2022-05-22 09:13:38 | test3 | 0    |
+----+---------------------+-------+------+
3 rows in set (0.00 sec)

— source 

mysql> UPDATE test1 SET name = 'foobar', d = CURRENT_TIMESTAMP WHERE a = 'test1' AND d = '2022-05-22 10:13:37';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from test1;
+----+---------------------+-------+--------+
| id | d                   | a     | name   |
+----+---------------------+-------+--------+
|  1 | 2022-05-22 10:16:15 | test1 | foobar |
|  2 | 2022-05-22 10:13:37 | test2 | 0      |
|  3 | 2022-05-22 10:13:38 | test3 | 0      |
+----+---------------------+-------+--------+
3 rows in set (0.00 sec)

— replica

mysql> select * from db1.test1;
+----+---------------------+-------+------+
| id | d                   | a     | name |
+----+---------------------+-------+------+
|  1 | 2022-05-22 09:13:37 | test1 | 0    |
|  2 | 2022-05-22 09:13:37 | test2 | 0    |
|  3 | 2022-05-22 09:13:38 | test3 | 0    |
+----+---------------------+-------+------+
3 rows in set (0.00 sec)

mysql> pager egrep "Running|SQL_Error"
PAGER set to 'egrep "Running|SQL_Error"'

mysql > show replica status\G
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
               Last_SQL_Error: 
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
     Last_SQL_Error_Timestamp: 
1 row in set (0.00 sec)

 

Another test, using UTC_TIME() compared against a column that was populated using the CURRENT_TIMESTAMP function:

— source 

mysql> select * from test1 WHERE TIME(d) > DATE_SUB(UTC_TIME(), INTERVAL 11 HOUR) AND id=3;
+----+---------------------+-------+------+
| id | d                   | a     | name |
+----+---------------------+-------+------+
|  3 | 2022-05-22 10:13:38 | test3 | 0    |
+----+---------------------+-------+------+
1 row in set (0.00 sec)

— replica

mysql> select * from test1 WHERE TIME(d) > DATE_SUB(UTC_TIME(), INTERVAL 11 HOUR) AND id=3;
Empty set (0.00 sec)

Therefore, when a similar condition is used for update:

— source

mysql> update test1 set name="bar" WHERE TIME(d) > DATE_SUB(UTC_TIME(), INTERVAL 11 HOUR) AND id=3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from test1 where id=3;
+----+---------------------+-------+------+
| id | d                   | a     | name |
+----+---------------------+-------+------+
|  3 | 2022-05-22 22:12:15 | test3 | bar  |
+----+---------------------+-------+------+
1 row in set (0.01 sec)

— replica

mysql> select * from test1 where id=3;
+----+---------------------+-------+------+
| id | d                   | a     | name |
+----+---------------------+-------+------+
|  3 | 2022-05-22 09:13:38 | test3 | 0    |
+----+---------------------+-------+------+
1 row in set (0.01 sec)

mysql > show replica status\G
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
               Last_SQL_Error: 
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
     Last_SQL_Error_Timestamp: 
1 row in set (0.00 sec)

Again replica ignored the update while there is no replication error reported. This particular scenario can be expected to happen really often in geographically-distributed database environments.

As the functions used here are not considered unsafe for replication, two usual safety actions are not performed:

• no warning is printed in the error log when the STATEMENT format used
• replication event is not logged in RBR format when the MIXED format is used but rather left the original query as it is

I find this potentially dangerous and hence reported it: https://bugs.mysql.com/bug.php?id=107293

Summary

ROW-based replication has become the standard in MySQL and is the most reliable one. It is also the only one permitted for virtually synchronous replication solutions like Percona XtraDB Cluster/Galera and MySQL Group Replication.

At the same time, STATEMENT or even MIXED format, may lead to data consistency issues, which can be undetected for a long time, making it very difficult to investigate when finally replication error happens as a result.

If there is anything that has prevented you from switching to ROW format yet, the sooner you deal with it the better.

Last week at Percona Live, I was asked what book I recommend for novices seeking to learn MySQL.  For a long time, there has not been a good choice for modern versions of MySQL. Luckily I had just stumbled upon such a book.  Now I am happy to recommend The MySQL Workshop – A practical guide to working with data and managing databases with MySQL by Petit and Cosentino.

The first chapter introduces database architectures, data types, storage engines (including MyRocks), and data normalization. The following chapter cover in great detail how to create a database, using MySQL Workbench, backups & restoring data, and creating indexes. Chapter four has a very good section on working with SQL, functions, and case statements. Then JOINs and stored procedures are covered.

In another book, that would probably be enough content, but later chapters plunge into using Node.JS, Access, and Excel with MySQL.

The last few chapters cover loading data from many file formats, JSON data usage, user permissions, and logical backups. While knot a comprehensive MySQL DBA guide this material is well done and complete.

That is a lot of content in seven hundred pages.  The writing style is clear and numerous examples are well done.  Bravo to the authors for their achievements in this book.

This may not be the reference text for a grizzled MySQL veteran but for real novices and intermediates, this book is a must-have.  This would be a great classroom text for an introduction to MySQL class or a handy hardcopy reference for someone on the initial climb of the learning curve.

MySQL allows changing the location of the general log and the slow query log while the server is running by anybody having the SYSTEM_VARIABLES_ADMIN privilege to any location, including appending to existing files. In Percona Server for MySQL 8.0.28-19 we introduced a new system variable, secure-log-path, that can be used to restrict the location of these log files to avoid accidents or possible data corruption attacks.

When somebody with the system variables admin privilege changes these variables, the server runs a few sanity checks. Unfortunately, these checks are quite minimal, and only verify that the specified file is writable by mysqld.

Compared to this, other variables specifying write-related file and directory names are either read-only during the runtime of the server (such as datadir, tmpdir, or log_error), or have additional security checks, for example, the FILE privilege restricted by secure-file-priv.

Without a mechanism like that, these log files can be redirected to any file writable by MySQL, such as ibdata0 or any other data file in the data directory. The server only appends to these files, and no data will be deleted from them, but this still makes it possible to corrupt these files by writing unrelated log messages into them.

To fix this issue, starting with Percona Server for MySQL 8.0.28-19 we introduced a new variable, secure-log-path. This works similarly to secure-file-priv: it can be either empty (which is the default) or the name of a directory. If it is specified, the general log file and the slow query log can only be set to a file within that directory.

Similar to secure-file-priv, the server will display a warning during startup if this new variable is empty, and also if the data directory is within it.

While these two variables are similar, it is also important that they are not the same: in most setups, users with the FILE privilege shouldn’t have read access to the log files written by mysqld using SQL commands, as that could leak potentially sensitive data. To avoid this, it is important to set them to different directories.

Percona Live 2022 in Austin has just ended, but we don’t waste time and we’ve prepared a new event for you. We understand that traveling still might be challenging for both speakers and attendees, and that’s why the event will be virtual. It will take place on June 21 – 23 and will be streamed on YouTube, LinkedIn, and Twitch.

For this event, we invited speakers whose amazing talks we were not able to accommodate in the tight schedule of Percona Live, and also other fantastic speakers.

Good news – we still accept submissions from everyone! We are looking forward to hearing from you!  We welcome any talks related to open source technologies, MySQL, PostgreSQL, MongoDB, MariaDB databases, and new & emerging technologies. The CFP closes on Monday, May 31. Don’t hesitate and send your abstracts here now!

Here are some of the amazing talks that are already on the schedule:

• Flexible Indexing with Postgres by Bruce Momjian (Postgres Evangelist, EDB)
• PMM on Kubernetes by Denys Kondratenko (Director of Software Engineering, Percona)
• The Open-Source Distributed Graph Database: Nebula Graph by Wey Gu (Developer Advocate, Vesoft)
• 10 Deadly PostgreSQL Sins by Matt Yonkovit (HOSS, Percona) and Barrett Chambers (Director, Solutions Engineering, Percona)
• I Dropped My Database! Now What? – A Dive Into PostgreSQL Backup Using pgBackRest and How to Use it for PITR by Charly Batista (Postgres Tech Lead, Percona)
• The MySQL Ecosystem in 2022 by Colin Charles (Codership)
• The Ways of Performance Schema and How to Leverage it for Troubleshooting by Leonardo Bacchi Fernandes (Support Engineer, Percona)

And more!

If you are not ready to talk, we welcome you to join the event as an attendee. Just come to our streams on YouTube, LinkedIn, or Twitch. All the updates will be published on the event’s page. Also, follow us on Twitter so as to not to miss the important news.

Percona Live 2022 is a wrap, and there was no better way to close out a great event than with our annual partner awards!

Each year, we’re honored to select a group of partners who’ve gone above and beyond to bring Percona’s products, support, and services to companies worldwide. These partners play a vital role in helping organizations modernize their database environments through the power and freedom of open source. 

“Successful partnerships not only provide opportunities to reach new clients, but also offer valuable insights into your customer’s needs,” said Giuseppe Vitulano, Executive Vice President, Global Sales at Percona. “Having these insights is a critical precondition for a tailored solution that addresses the core business needs of the end client.”

During this year’s ceremony, live for the first time in two years, our partners took home awards in two categories: Most Valuable Partner and Strategic Partner of the Year.

Most Valuable Partner awards

Percona’s Most Valuable Partner (MVP) awards are given regionally to those companies who co-sell Percona products and services and provide an additional layer of technical value to customers.

America’s Most Valuable Partner

Paragon Micro, United States

Paragon Micro helps customers solve complex IT challenges and deliver the desired business outcome through next-generation IT technology solutions.

“We’re honored to accept this award. This partnership allows Paragon Micro to remain on the leading edge of the database field by expanding the tools and resources that we have intimate access to as a result of the strength of our growing partnership with Percona.” – Joe Yamour, Vice President of Public Sector, Paragon Micro

“Paragon has demonstrated all of the skills we are looking for from our Reseller Partners.   Proactive, great communication, eager to learn more, and laser focus on the customer’s needs, I am very bullish on what we can achieve together with Paragon Micro. In particular, with the teams that they are building in the public sector and internationally.“  – Bill Irwin, Vice President, Sales, Americas, Percona 

Joe Yamour, Vice President of Public Sector, Paragon Micro, accepting MVP award

EMEA Most Valuable Partner

NessPRO, Israel

NessPRO, the software distribution arm of Ness Technologies, empowers customers through advanced software solutions that facilitate enhanced business and operation efficiencies in the era of digital transformation.

“Prominent Israeli companies in the financial sector and in the high-tech industry are looking to move from relational to NoSQL databases. These companies are showing great interest in Percona server for MongoDB and are conducting feasibility studies. The feedback we’re receiving from them is excellent. We believe these companies will adopt Percona as part of their architecture. Percona’s products and services enable record database performance and allow technical teams to focus on issues related to their organizations’ core business. Today, open source databases are extremely complex with large workloads, and their maintenance requires a great deal of knowledge and experience. Percona experts provide the best products and services to ensure optimal operation of the databases.” – Eli Alafi, Director Data and Innovation at NessPRO, Ness’ software products group

“Eli and the team at Ness Technologies are superb partners. They are technically adept, have database intelligence and offerings, and continue to position Percona offerings to their customers. We are happy to have a platform to acknowledge our partnership and the way they add value by helping us scale to new customers and new technical conversations.”- Jason Meshberg, Head of Resellers and Channels, Percona   

Elena Bugnet, Percona Partner Sales Manager, EMEA, accepting MVP award on behalf of Ness Technology Israel

APAC Most Valuable Partner

Smartstyle, Japan

Smartstyle is an IT solutions company specializing in MySQL. 

“We are honored to be named a Percona Most Valuable Partner and appreciate this award as recognition of our long-term partnership. SmartStyle has worked with Percona since 2013, selling licenses and providing technical support to Japanese customers. Our engineers are constantly improving their skills in service to our clients, and thanks to Percona’s excellent products and support, which our customers value, we have been rapidly growing and developing as a company. Together with the community of database performance experts and inspired by this award, we will continue to drive better technology and work hard to provide even better support and services to  our customers.” – SmartStyle

“Smartstyle has uniquely taken care of many customers with Percona in Japan by providing L0/L1 support and important translation and language support. Smartstyle works closely with our account and customer success teams to achieve strong business outcomes for our Japanese customers. I am proud to acknowledge our partnership and friendship and be able to rely on Smartstyle to communicate product innovations with Percona Platform.” –Jason Meshberg, Head of Resellers and Channels, Percona  

Aditya Pulastaya, Percona Partner Sales Manager, APAC, accepting MVP award on behalf of SmartStyle Japan.

Strategic Partner of the Year award

Each year, Percona’s Strategic Partner of the Year Award honors one company that has been most instrumental in helping to drive Percona’s technology and growth strategy. 

Amazon Web Services 

Amazon Web Service is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally.

“AWS is receiving this acknowledgement due to the various engagements we have with their teams. AWS teams have leveraged our expertise in high performance databases to accelerate customer cloud journeys. We endeavor to do more with an active path to marketplace automation and a consistent partner development model where we continue to find new grounds and new customers that can benefit from our partnership.” – Jason Meshberg, Head of Resellers and Channels, Percona

Congratulations to all the winners! See you next year at Percona Live 2023. 

Become a Percona partner

To learn more about the Percona partner program, please email us at partners@percona.com.