We had great attendance, questions, and feedback from our “Converting MongoDB to Percona Server for MongoDB” webinar, which was recorded and can be viewed here. You can view another Q&A from a previous webinar on “Converting MongoDB to Percona Server for MongoDB” here. Without further ado, here are your questions and their responses.
Q: If migrating from MongoDB Enterprise Edition to Percona Server for MongoDB, can implementations that use LDAP or Kerberos be migrated using the replica set takeover method to avoid excessive downtime?
A: The intended design when using these two features is that Percona Server for MongoDB (PSMDB) remains a true drop-in replacement. This means no configuration changes will be necessary. This should be tested before go-live to ensure success.
The above is valid for the Audit Plugin as well, which is a free feature that is included in the enterprise version.
Q: Does the replica set takeover method also work for sharded implementations of MongoDB that use configdb replica sets?
A: Yes, it does, although there are a few more steps to consider as you do not want chunks migrating while you are upgrading.
To convert a sharded cluster to Percona Server for MongoDB, you would:
- Disable the balancer (sh.stopBalancer() )
- Convert the config servers (replica set takeover method)
- Upgrade the shards (replica set takeover method)
- Upgrade the mongos instances
- Re-enable the balancer (sh.startBalancer())
Q: Is it necessary to make any change on the driver/application side?
A: No. The drivers have the same compatibility for PSMDB.
Q: Does Percona Monitoring and Management (PMM) support alerting?
A: Yes, PMM supports alerting. This blog post discusses the new and upcoming PMM native alerting, this documentation shows how to configure Prometheus AlertManager integration, and this documentation shows how to utilize Grafana Alerts.
Q: When is best to migrate from MySQL to MongoDB, and in what scenario would MongoDB be the best replacement?
A: This is a complicated question without a simple answer. It depends on the application workload, internal business directives, internal technology directives, and in-house expertise availability. In general, we recommend choosing the right tool for the right job. In that sense, MySQL was built for structured, relational, and transactional workloads, while MongoDB was built for an unstructured, JSON document model without a lot of transactions linking collections. While you technically can cross-pollinate both models between MySQL and MongoDB, we do not recommend doing so unless there is good reason to do so. This is the perfect scenario to engage with Percona consulting for true expert input in the decision making process.
