You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pinot.apache.org by GitBox <gi...@apache.org> on 2018/11/16 19:26:43 UTC
[GitHub] jfim opened a new pull request #3506: Add configuration merging tool
jfim opened a new pull request #3506: Add configuration merging tool
URL: https://github.com/apache/incubator-pinot/pull/3506
Add a configuration merging tool to aid in migration between old-style
configurations and the new style configuration. Configurations can be
migrated by backing up tables using the config backup tool, then merging
them.
The merging is only necessary if configurations for multiple
configuration profiles are desired. This happens when multiple Pinot
clusters are managed using configuration profiles and a single source of
truth for configurations is desired.
For example, given multiple Pinot clusters in multiple data centers, one
might have two staging clusters and two production clusters. Since the
configuration backup tool only backs up the configuration for a single
Pinot cluster, without merging there would be one set of configurations
for each cluster. With config merging, one would end up with identical
keys merged across configurations (eg. table.name is the same across all
clusters) and different keys across configurations being merged (eg.
table.replication___staging=1 and table.replication___prod=3).
An optimization process is applied to minimize the number of generated
keys in the case where there are heterogenous combinations of clusters
with multiple profiles applied to them. For example, the combination
table.replication___staging=1 and table.replication___prod=3 is
preferred over table.replication___staging-us-west1=1,
table.replication___staging-us-east1=1,
table.replication___prod-us-west1=3, table.replication___us-east1=3 even
though both combinations expand to the same data.
Furthermore, a substitution process is applied to replace values by
configuration values read from the existing profiles. For example, if a
profile exists for "prod-us-east1" that contains
"kafka.broker=kafka-us-east1:2181", configuration keys that have the
value "kafka-us-east1:2181" and the "prod-us-east1" configuration
profile enabled will get replaced with "${kafka.broker}". In the case
where multiple replacements are possible, a minimization process is
applied to generate the smallest set of generated keys, similar to the
configuration optimization for keys that differ across clusters.
Thus, the migration process is:
1. Write the per profile configuration files (eg. profile/staging.conf,
profile/staging-us-east1.conf", ...)
2. Back up configuration files using the table config backup tool in
directories that contain the profile tags to be applied for that
cluster. For example, data from the staging-us-west1 cluster would be
backed up to configBackup/staging/staging-us-west1 so that
configuration files in that directory are understood to have the
staging and staging-us-west1 configuration profiles.
3. Invoke the configuration merger with the configBackup directory as
input.
4. Review the generated merged files for stylistic preferences, as
desired.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pinot.apache.org
For additional commands, e-mail: dev-help@pinot.apache.org