Difference between revisions of "Server maintenence"
old>Admin |
old>Admin |
||
Line 1: | Line 1: | ||
== Server automated services == | == Server automated services == | ||
This is the installation procedure for remote backup and monitoring. | |||
Prerequisites: | |||
* SSH accces to the servere | |||
* TS commandline tools have been installed and up to date | |||
=== Set up monitoring === | |||
# Log in into [UptimeRobot.com] | |||
# Create a new monitor | |||
## | |||
## | |||
## | |||
## | |||
# Tjeck the monitor is working | |||
=== Set up remote backup === | |||
==== Client server setup ==== | |||
==== Backup server setup ==== | |||
== Server monitor page == | == Server monitor page == |
Revision as of 07:28, 26 August 2020
Server automated services
This is the installation procedure for remote backup and monitoring.
Prerequisites:
- SSH accces to the servere
- TS commandline tools have been installed and up to date
Set up monitoring
- Log in into [UptimeRobot.com]
- Create a new monitor
- Tjeck the monitor is working
Set up remote backup
Client server setup
Backup server setup
Server monitor page
Each application contains a public page that can be queried for server status.
The page is: http://SERVER/APPLICATION/service?PASSWORD
Password can be set in the configuration: healthMonitorPassword
Reponse will look something like
<serverstatus>
<flag name="Source version">2081</flag>
<flag name="Unused storage">27%</flag>
<flag name="Database motor">OK</flag>
<flag name="Authentication">OK</flag>
<flag name="Daemon running">NO</flag>
<flag name="Server healthy">HEALTHY</flag>
<flag name="Is user online">NO</flag>
<flag name="Session length">30</flag>
<flag name="DB schema LIVE">tslive</flag>
<flag name="DB schema TEST">tstest</flag>
<flag name="Last view data">2013-02-12 16:53:11</flag>
<flag name="Last exception">2013-02-12 12:28:16</flag>
</serverstatus>
If the goodword HEALTY is found the following things are ok
- Server is open for logins
- DB connections are accessible
- Data / log disc is not full
A good option for an online monitoring tool is Site24x7 which we strongly recommend.
Backup and restore
TS has inbuilt manual functions on the solution level, but measures have to taken to back the data IN the solutions.
Backups should optimally be done either by dumping the database. Alternatively the database can be stopped (important) and data folders can be backed up normally.
The following guide contains directions for setting up incremental backups to remote location, using rsync and SSH connections.
http://tempusserva.dk/mediawiki/index.php?title=Backup_and_restore
Table naming conventions
Every solution has its own table namespace of "data_" followed by the system solution name.
Example for the solution named XXX:
- data_XXX
Other related tables include
- data_XXX_file
- data_XXX_mail
- data_XXX_comment
- data_XXX_contact
- data_XXX_measure
- data_XXX_member
- data_XXX_t_YYY
- data_XXX_accesslog
- data_XXX_statuslog
- data_XXX_revisionlog
Deleted tables are prefixed by a timestamp
Accessing the database (MySQL)
Normally Tempus Serva will maintain the database by itself.
Sometimes direct access is needed, for example
- Partial table data restore
- Sharding large tables (+1M records or many Blobs)
We recommend the following database tool
Other client tools include
URL redirects and rewrites
Tempus Serva (version 2090+) contains server filters for URL rewrite, redirects and forwards.
The filter is deactivated by default, but can be enabled by
- Rename /WEB-INF/web.xml.urlrewrite to web.xml
- Change /WEB-INF/urlrewrite.xml as needed
- Restart the server
Other options include merging web.xml.urlrewrite into the existing web.xml.
Documentation can be found in following pages