Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
Hi,
We are deploying Thingworx 8.4 on Azure VM with connectivity to Azure managed Postgres. Our production would comprise of 3 instances of Azure VM running Thingworx platform and all of them connected to one DB (with geo-redundancy soln)
Could someone clarify following questions please?
1. All logs are stored in ThingworxStorage folder. As per the details given in post below, "If ThingworxStorage folder is accidentally deleted, entities and data are secure in the external database".
https://www.ptc.com/en/support/article?n=CS257403&source=snippet
a) Which DB tables are these logs stored?
b) Can I configure two postgres DB such that transactional logs are pushed into one DB while Thingworx configurations go into another postgres DB? If yes, then where can I set the DB connection strings?
2. I believe the License is loaded in DB. So for running Thingworx Platform on 3 VM instances with one DB, do I need to purchase 3 licenses from PTC as each Thingworx platform would generate its own device id?
Solved! Go to Solution.
I think you might be mixing up some different logs.
Thingworx uses a local or mapped ThingworxStorage folder to store the Thingworx application/script/etc logs and these are stored as .log files (text files)
These are NOT transaction logs in terms of how Databases have transaction logs.
Thingworx stores all Model information and persisted data in the Persistence Provider (Database)
You can map drives so all Thingworx instances use the same ThingworxStorage folder BUT this should NOT be the case for the LOGs folder, because concurrent writes to the same log file can cause hanging threads and issues within the Thingworx platform.
You can NOT have multiple active Thingworx instances use the exact same persistence provider, this will cause locking issues that will crash Thingworx.
Right now there is no true horizontal scaling in Thingworx where hopefully in the future this becomes a possible scenario.
If you look at how Thingworx HA works right now with Zookeeper, it has all Thingworx nodes with Tomcat running and Thingworx initialized, but Zookeeper designates the instance of Thingworx that is actually connected to the Persistence Provider. ie. only one active instance is connected to the database at one time.
Hopefully this clears up some things for you.
I think you might be mixing up some different logs.
Thingworx uses a local or mapped ThingworxStorage folder to store the Thingworx application/script/etc logs and these are stored as .log files (text files)
These are NOT transaction logs in terms of how Databases have transaction logs.
Thingworx stores all Model information and persisted data in the Persistence Provider (Database)
You can map drives so all Thingworx instances use the same ThingworxStorage folder BUT this should NOT be the case for the LOGs folder, because concurrent writes to the same log file can cause hanging threads and issues within the Thingworx platform.
You can NOT have multiple active Thingworx instances use the exact same persistence provider, this will cause locking issues that will crash Thingworx.
Right now there is no true horizontal scaling in Thingworx where hopefully in the future this becomes a possible scenario.
If you look at how Thingworx HA works right now with Zookeeper, it has all Thingworx nodes with Tomcat running and Thingworx initialized, but Zookeeper designates the instance of Thingworx that is actually connected to the Persistence Provider. ie. only one active instance is connected to the database at one time.
Hopefully this clears up some things for you.