Pros and Cons of Database in a container for EventSentry
I
Ingmar Koecher
started a topic
about 5 years ago
Hi,
what are your perceived pros and cons of having a containerized database for EventSentry installation?
For bigger enviroments that could be added resilency of DB cluster but is that a case for smaller installations?
Whats your point of view on this topic?
I'm leaning toward PostgreSQL but a question may be relevant to any DB.
Best Answer
S
Sally
said
about 5 years ago
EventSentry really only cares that it can reach the database to write data and read data, and that your database storage performs adequately for the amount of events per second that are being written to the database.
For smaller installations you would not need to bother with anything other than the default settings and let EventSentry install and manage the database for you. Even for most of the medium and large installations, unless your storage is too slow you would only need to optimize the Postgres settings (https://www.eventsentry.com/kb/232) and possibly set up a junction (symlink) to point the Postgres WAL at a separate drive since the Postgres configuration does not allow you to directly specify a WAL location. For Microsoft SQL you'd want to make sure you have optimized autogrowth settings for your MDF and LDF files, and that the MDF and LDF are on separate disks from one another, and other common performance recommendations from the Microsoft SQL documentation.
If you want to do anything else with the database such as containers or clusters, as long as it does not reduce the write performance of the database in your environment, go right ahead. One thing to watch out for is that if you do clustering directly within Microsoft SQL, it will change the database recovery mode to FULL, which for almost all situations will cause lots of transaction log disk usage/storage problems when you purge from the database. You'd need to have a script that changes the recovery mode to SIMPLE, purges your data, and then changes the recovery mode back to FULL so that the clustering works again.
1 Comment
S
Sally
said
about 5 years ago
Answer
EventSentry really only cares that it can reach the database to write data and read data, and that your database storage performs adequately for the amount of events per second that are being written to the database.
For smaller installations you would not need to bother with anything other than the default settings and let EventSentry install and manage the database for you. Even for most of the medium and large installations, unless your storage is too slow you would only need to optimize the Postgres settings (https://www.eventsentry.com/kb/232) and possibly set up a junction (symlink) to point the Postgres WAL at a separate drive since the Postgres configuration does not allow you to directly specify a WAL location. For Microsoft SQL you'd want to make sure you have optimized autogrowth settings for your MDF and LDF files, and that the MDF and LDF are on separate disks from one another, and other common performance recommendations from the Microsoft SQL documentation.
If you want to do anything else with the database such as containers or clusters, as long as it does not reduce the write performance of the database in your environment, go right ahead. One thing to watch out for is that if you do clustering directly within Microsoft SQL, it will change the database recovery mode to FULL, which for almost all situations will cause lots of transaction log disk usage/storage problems when you purge from the database. You'd need to have a script that changes the recovery mode to SIMPLE, purges your data, and then changes the recovery mode back to FULL so that the clustering works again.
Ingmar Koecher
Hi,
what are your perceived pros and cons of having a containerized database for EventSentry installation?
For bigger enviroments that could be added resilency of DB cluster but is that a case for smaller installations?
Whats your point of view on this topic?
I'm leaning toward PostgreSQL but a question may be relevant to any DB.
EventSentry really only cares that it can reach the database to write data and read data, and that your database storage performs adequately for the amount of events per second that are being written to the database.
For smaller installations you would not need to bother with anything other than the default settings and let EventSentry install and manage the database for you. Even for most of the medium and large installations, unless your storage is too slow you would only need to optimize the Postgres settings (https://www.eventsentry.com/kb/232) and possibly set up a junction (symlink) to point the Postgres WAL at a separate drive since the Postgres configuration does not allow you to directly specify a WAL location. For Microsoft SQL you'd want to make sure you have optimized autogrowth settings for your MDF and LDF files, and that the MDF and LDF are on separate disks from one another, and other common performance recommendations from the Microsoft SQL documentation.
If you want to do anything else with the database such as containers or clusters, as long as it does not reduce the write performance of the database in your environment, go right ahead. One thing to watch out for is that if you do clustering directly within Microsoft SQL, it will change the database recovery mode to FULL, which for almost all situations will cause lots of transaction log disk usage/storage problems when you purge from the database. You'd need to have a script that changes the recovery mode to SIMPLE, purges your data, and then changes the recovery mode back to FULL so that the clustering works again.
Sally
EventSentry really only cares that it can reach the database to write data and read data, and that your database storage performs adequately for the amount of events per second that are being written to the database.
For smaller installations you would not need to bother with anything other than the default settings and let EventSentry install and manage the database for you. Even for most of the medium and large installations, unless your storage is too slow you would only need to optimize the Postgres settings (https://www.eventsentry.com/kb/232) and possibly set up a junction (symlink) to point the Postgres WAL at a separate drive since the Postgres configuration does not allow you to directly specify a WAL location. For Microsoft SQL you'd want to make sure you have optimized autogrowth settings for your MDF and LDF files, and that the MDF and LDF are on separate disks from one another, and other common performance recommendations from the Microsoft SQL documentation.
If you want to do anything else with the database such as containers or clusters, as long as it does not reduce the write performance of the database in your environment, go right ahead. One thing to watch out for is that if you do clustering directly within Microsoft SQL, it will change the database recovery mode to FULL, which for almost all situations will cause lots of transaction log disk usage/storage problems when you purge from the database. You'd need to have a script that changes the recovery mode to SIMPLE, purges your data, and then changes the recovery mode back to FULL so that the clustering works again.
-
EventSentry SQL Backup
-
Freeing up disk space
-
"The RPC server is unavailable" when trying to add any computer.
-
How to remove a list of Servers/Agents using a CSV
-
PostgreSQL error
-
After installing trial with a collector, then removing the collector, Agents appear Disconnect or Frozen
-
Can EventSentry Light be used to monitor a phone server on my network?
-
Support for Windows Server 2019
-
Syslog Search Syntax
See all 37 topics