I have technical concept questions, it also could be a good points for the upcoming discussion at Fri April 3.
- Concept of replacing IDO-MySQL with IcingaDB have the following goals in my understanding
- a) Increase speed for JSON-RPC queue utilisation
- b) Faster configuration update during deployment, e.g. adding/removing hosts & services
- c) Reduce MySQL update/select operations for temporary data (especially host_state & service_state tables)
IcingaDB MySQL schema holds host_state and service_state tables and actively update it.
My database statistics during the test with 100k services per minute show the following:
MariaDB [icingadb]> SHOW ENGINE INNODB STATUS;
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=11918, Main thread ID=140418679252736, state: sleeping
Number of rows inserted 1176936, updated 27526120, deleted 535381, read 247877366
0.00 inserts/s, 0.33 updates/s, 0.00 deletes/s, 0.41 reads/s
Number of system rows inserted 19, updated 0, deleted 19, read 43
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
We can still see here a lot of reads & updates which i expected to be handled by Redis.
- Concept of Icingaweb utilisation of Redis
Setting incorrect Redis master address still allow me to drill the actual info from IcingaWeb:
Password field missed which is not transparent with IcingaDB config: https://github.com/Icinga/icingadb/blob/master/config/config.go#L23
For now I can only guess what requests going from Icingaweb to Redis and i would like to see a clear schema of data/request flows, also wondering why we still have host_state and service_state tables still present in MySQL
- Concept of Environments
Mentioned at https://icinga.com/docs/icingadb/latest/
Icinga DB also supports reading from multiple environments and writing into a single MySQL instance.
Could you please provide additional information and/or documentation of how to configure it and for what cases it could be useful.
P.S. Like new Redis implementation through the streams