2017-01-29 13:33:33 -06:00
|
|
|
[Unit]
|
|
|
|
|
Description=Database container
|
|
|
|
|
Requires=docker.service
|
|
|
|
|
After=docker.service
|
create multiple Redis DB instances based on CONFIG at /etc/sonic/database_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 Azure/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
2019-08-28 13:15:10 -05:00
|
|
|
After=rc-local.service
|
2020-02-11 16:03:02 -06:00
|
|
|
StartLimitIntervalSec=1200
|
|
|
|
|
StartLimitBurst=3
|
2017-01-29 13:33:33 -06:00
|
|
|
|
|
|
|
|
[Service]
|
2018-11-22 17:13:35 -06:00
|
|
|
User=root
|
[oneimage]: Fix race condition in systemd container services (#421)
When Type=simple, systemd will consider the service activated immediately
after specified in ExecStart process is started. If there is downstream
service depending on the state prepared in ExecStart, there will be race condition.
For example, issue #390. In this case, database.service calls database.sh, which
calls docker run or docker start -a to start database container. However, systemd
considers database.service successfully started at the time database.sh begins,
not after docker run finishes. As database.service is consider started, bgp.service
can be started. The redis database, which bgp service depends on, might or might not
have been started at this time point.
To fix this issue (and still keeping the functionality to monitor docker status with
systemd), we split the ExecStart process into an ExecStartPre part and an ExecStart
part. docker run is splitted into docker run -d then docker attach , while docker start
-a is splitted into docker start and then docker attach. In this way, we make sure
the downstream services are blocked until container is successfully started.
2017-03-22 15:04:48 -05:00
|
|
|
ExecStartPre=/usr/bin/{{docker_container_name}}.sh start
|
2019-03-08 12:59:41 -06:00
|
|
|
ExecStart=/usr/bin/{{docker_container_name}}.sh wait
|
2017-01-29 13:33:33 -06:00
|
|
|
ExecStop=/usr/bin/{{docker_container_name}}.sh stop
|
2020-02-11 16:03:02 -06:00
|
|
|
Restart=always
|
|
|
|
|
RestartSec=30
|
2017-01-29 13:33:33 -06:00
|
|
|
|
|
|
|
|
[Install]
|
|
|
|
|
WantedBy=multi-user.target
|
