You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mongo Atlas is allowing the creation of analytics nodes, that can be used to protect the operational performance of the production database. Such solution is ideal for our use of the mongo_fdw (as a reporting sql service) because we’re having issues with excessive workload and currently the only option we have is to pull data from the primary or secondary in the main node, while the recommended solution from Mongo Altas isn't that but the creation of an analytics node.
However, currently the to be mongo_fdw meta driver doesn't allow us to use that node which is more suitable because it doesn't accept the ‘readPreferenceTags’ as a generic way of passing parameters. The addition of such feature would generate a great value being useful not only for analytics nodes, but also pulling traffic from a specific region of a sharded cluster as, for example, just from a local read-only node in Germany. It would avoid the need of pushing all the dataset instead of a single part of it. In other words: with a single tag like 'readPreferenceTags=nodeType:ANALYTICS' as a parameter in the MongoDB foreign server object we could, at the same time, solve our problem with our reporting server and many other problems as with sharded clusters.
As we said, we believe this is a feature that is not only useful for us but for many users of the mongo_fdw metadriver.
As we have some urgency on this could you please allow us to know if there are any plans of including this in a near future update?
Thanks a lot for your time.
The text was updated successfully, but these errors were encountered:
Currently this is not our highest priority but we may consider this in near future. However, If you want, feel free to post a patch which we will discuss/review further.
We have the same need requested by @AmoraRosa. Without this Mongo Atlas it is unnecessarily overloading our main Mongo Atlas cluster, and this overload is increasing to the point where we are unable to continue using mongo fdw in a not too distant future. If we can't solve this soon we may have to look another alternative to mongo_fdw. : /
Mongo Atlas is allowing the creation of analytics nodes, that can be used to protect the operational performance of the production database. Such solution is ideal for our use of the mongo_fdw (as a reporting sql service) because we’re having issues with excessive workload and currently the only option we have is to pull data from the primary or secondary in the main node, while the recommended solution from Mongo Altas isn't that but the creation of an analytics node.
However, currently the to be mongo_fdw meta driver doesn't allow us to use that node which is more suitable because it doesn't accept the ‘readPreferenceTags’ as a generic way of passing parameters. The addition of such feature would generate a great value being useful not only for analytics nodes, but also pulling traffic from a specific region of a sharded cluster as, for example, just from a local read-only node in Germany. It would avoid the need of pushing all the dataset instead of a single part of it. In other words: with a single tag like 'readPreferenceTags=nodeType:ANALYTICS' as a parameter in the MongoDB foreign server object we could, at the same time, solve our problem with our reporting server and many other problems as with sharded clusters.
This is the article from mongoDB about analytics nodes and how to connect to them:
https://www.mongodb.com/blog/post/atlas-mapped-analytics-nodes-to-power-your-bi-are-now-available
As we said, we believe this is a feature that is not only useful for us but for many users of the mongo_fdw metadriver.
As we have some urgency on this could you please allow us to know if there are any plans of including this in a near future update?
Thanks a lot for your time.
The text was updated successfully, but these errors were encountered: