-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design of creating user defined multiple database instances #271
Conversation
68c22f2
to
a1bc19e
Compare
@lguohan @qiluo-msft @jipanyang |
you mentioned that to use redis cluster solution, client has to use TCP + PORT instead of unix socket, do you have some rough single client read/write performance benchmark for the two different connections against single redis instance? |
update the benchmark result in DOC |
- [x] **generate corresponding runtime ping/PONG check script as well to check if database instances are running later** | ||
- [x] **docker ENTRYPOINT : docker_init.sh** | ||
- [x] **at this point, we know the DATABASE configuration in database_config.json** | ||
- [x] **generate supervisord.conf and all redis.conf before database docker start** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it has been agreed that database instance configuration should be available at build time, no supervisord.conf needs to be generated on the fly during running time, could you update the description here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
}, | ||
"redis_ins_002":{ | ||
"port": 6381, | ||
"databases" : ["APPL_DB","ASIC_DB", "CONFIG_DB"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though this is just an example configuration, as a more reasonable db allocation among instances, probably APPL_DB","ASIC_DB", "CONFIG_DB" should be put into different db instances to make parallel db processing possible at critical path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
MSET (10 keys): 5550.62 requests per second | ||
``` | ||
|
||
**So I don't think redis cluster is a good way to solve the problem of splitting databases into multiple redis instances in SONiC.** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One concern I have about deploying redis cluster in sonic is that redis cluster replicates data among multiple redis instances asynchronously and doesn't guarantee strong consistency. Not sure whether it is possible that different client may get different data view.
For backward compatibility, please keep the option to specify unix socket for each redis instance. We prefer it for performance issue. #Closed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As comments
we have uinx socket, by default each inistance has a unix socket at "/var/run/instance_name/instance_name.sock", you mean the user define the unix socket path and name in database_config.json file ? #Closed |
Thanks! Reading through the document, I am not aware this design detail. In reply to: 481505546 [](ancestors = 481505546) |
ed69d42
to
fe22fa0
Compare
…base_config.json (#2182) this is the first step to moving different databases tables into different database instances in this PR, only handle multiple database instances creation based on user configuration at /etc/sonic/database_config.json we keep current method to create single database instance if no extra/new DATABASE configuration exist in database_config.json file. if user try to configure more db instances at database_config.json , we create those new db instances along with the original db instance existing today. The configuration is as below, later we can add more db related information if needed: { ... "DATABASE": { "redis-db-01" : { "port" : "6380", "database": ["APPL_DB", "STATE_DB"] }, "redis-db-02" : { "port" : "6381", "database":["ASIC_DB"] }, } ... } The detail description is at design doc at sonic-net/SONiC#271 The main idea is : when database.sh started, we check the configuration and generate corresponding scripts. rc.local service handle old_config copy when loading new images, there is no dependency between rc.local and database service today, for safety and make sure the copy operation are done before database try to read it, we make database service run after rc.local Then database docker started, we check the configuration and generate corresponding scripts/.conf in database docker as well. based on those conf, we create databases instances as required. at last, we ping_pong check database are up and continue Signed-off-by: Dong Zhang d.zhang@alibaba-inc.com
fe22fa0
to
b24ce54
Compare
886c20b
to
41f3c94
Compare
…base_config.json (sonic-net#2182) this is the first step to moving different databases tables into different database instances in this PR, only handle multiple database instances creation based on user configuration at /etc/sonic/database_config.json we keep current method to create single database instance if no extra/new DATABASE configuration exist in database_config.json file. if user try to configure more db instances at database_config.json , we create those new db instances along with the original db instance existing today. The configuration is as below, later we can add more db related information if needed: { ... "DATABASE": { "redis-db-01" : { "port" : "6380", "database": ["APPL_DB", "STATE_DB"] }, "redis-db-02" : { "port" : "6381", "database":["ASIC_DB"] }, } ... } The detail description is at design doc at sonic-net/SONiC#271 The main idea is : when database.sh started, we check the configuration and generate corresponding scripts. rc.local service handle old_config copy when loading new images, there is no dependency between rc.local and database service today, for safety and make sure the copy operation are done before database try to read it, we make database service run after rc.local Then database docker started, we check the configuration and generate corresponding scripts/.conf in database docker as well. based on those conf, we create databases instances as required. at last, we ping_pong check database are up and continue Signed-off-by: Dong Zhang d.zhang@alibaba-inc.com
Signed-off-by: Dong Zhang d.zhang@alibaba-inc.com