How to recreate tplog file and write it again in kdb - kdb

Question

I accidentally removed the tplogs in the box. How can I create the log file again and connect to the log file in the tickerplant without affect the data in memory?
I know .u.L shows the path and .u.i is the count of the tplogs.
It is weird that .u.i still gives me the count when the file is already removed.
If I create and connect to the tplog again, will it be the only tplog its written?

Answer 1

.u.i counts the messages as they flow to the log file, it has no awareness of you deleting the log file so wouldn't reflect that. When a tp starts up it will call .u.ld which will do a count of the messages in the log file to set .u.i/j if the log file already exists on startup.
https://github.com/KxSystems/kdb-tick/blob/afc67eda6dfbb2ca89322f702db23ee68c2c7be3/tick.q#L29
You could use it to open a new file and reset .u.i/j/l/L. .u.ld .z.D.
*** If this is production were this has been done, I would break qa/uat and attempt this there first.
To answer your last question, if you re-create the tplog, only the messages written to the new log from that point will be saved. If your end of day is dependent on reading the log file then you will need to figure out an alternative with the rdb. If you are using an rdb/wdb for end of day and nothing goes wrong the messages will be retained. If rdb dies there will be no log to replay and data will be lost. Wdb will have most data already written to disk but you would need to be careful in it's startup if it died. If by default it removes the intra-day db and replays log it would delete the data and be unrecoverable.

Answer 2

This is somewhat related to your question, but it is possible to retroactively re-create a tickerplant log either from an in-memory table (if you still had it living in an RDB) or an on-disk table (if your system did manage to write from the RDB to the HDB). However recreating it exactly as it would have been in the live situation could be tricky, especially if you have a lot of tables that would be in the log.
In-mem table
.[`:/path/to/myTPlog;();:;()];
l:hopen`:/path/to/myTPlog;
{l enlist(`upd;`tabName;value x)}each select from tabName;
One issue here is that this would do one table in a full sequence, whereas in realtime you more likely had multiple tables intertwined based on the live timestamps. You could try to piece the log together chronologially across various tables in a lock-step time sequence but that would require a bit more work and memory.
If you were happy to write entire tables to the log one-at-a-time then you could even write the entire table as one upd:
l enlist(`upd;`tabName;value flip select from tabName);
On-disk table
unenum:{#[x; where type'[flip x] within 20 77h; value]};
{l enlist(`upd;`tabName;value x)}each delete date from unenum[select from tabName where date=.z.D-1];