Freshmark Replication Server State
Last updated: 2026-03-30 UTC
Operating system
- Hostname:
freshmark-replication - OS: Ubuntu
24.04.3 LTS(noble) - Kernel:
6.8.0-87-generic - Architecture:
x86_64 aptversion:2.8.3
Package manager status
- Apt metadata refresh observed at
2026-03-15 02:24:05 UTC - Upgradable packages observed:
68 - Simulated upgrade summary:
68 upgraded, 0 newly installed, 0 to remove, 0 not upgraded - Held packages: none
dpkg --audit: cleanapt-daily.serviceandapt-daily-upgrade.service: inactive at check time
Container and database state
- Running container:
mariadb-production - Image:
freshmark/mariadb:10.1-prod-latest - Published port:
3306 - Live databases observed:
archivecptarchfmsfms_arcfmsdemozfmswfmsxfmszinformation_schemamysqlperformance_schemareplication_audittest
Current replication state
Observed on 2026-03-30T20:53:37Z via the live Canonical inventory API.
- Replica status:
healthy Slave_IO_Running=YesSlave_SQL_Running=YesSeconds_Behind_Master=0- Human status:
caught up - Master:
196.11.250.14:3306 - Current log position:
mysql-bin.000291at159798810 - Slave I/O state:
Waiting for master to send event
Replication recovery
Observed on 2026-03-16 UTC.
- Replica SQL thread was stopped with
Last_Errno=1146. - The blocking error was:
Table 'archive.mkt_daily_stats_2026' doesn't exist. archive.mkt_daily_stats_2025exists as a yearly MyISAM table, soarchive.mkt_daily_stats_2026was created withCREATE TABLE ... LIKE.- Restarting the SQL thread surfaced the same rollover gap for
archive.mkt_buyer_trans_2026. - An inventory of
archiveyearly tables found46more_2025tables without_2026counterparts, and those_2026tables were created from their matching_2025definitions. - After restarting the SQL thread again, replication resumed with
Slave_IO_Running=Yes,Slave_SQL_Running=Yes,Last_Errno=0, andLast_Errorempty. - The replica is still catching up from backlog rather than being fully current yet:
Seconds_Behind_Masterwas about6.21Mseconds and falling, andExec_Master_Log_Poscontinued to advance onmysql-bin.000282. - Confirmed replicated rows were landing in the newly created yearly tables, including
archive.mkt_daily_stats_2026andarchive.mkt_buyer_trans_2026.
Reverse proxy and WireGuard
Observed on 2026-03-30 UTC.
- Public Canonical URL:
https://freshmark-canonical.reverse-proxy.co.za - RPCTM public IP:
154.65.108.7 - RPCTM WireGuard server:
10.99.0.1/24 - Freshmark Canonical WireGuard client:
10.99.0.140/32 - RPCTM nginx upstream target:
http://10.99.0.140:8400 - Local app service:
freshmark-canonical.service - Local WireGuard service:
wg-quick@wg0 - Public certificate expiry:
2026-06-28 19:35:58+00:00
Important note:
The reverse proxy is live and healthy, but the app still listens directly on 0.0.0.0:8400 on the replication host. Tightening that exposure is still a follow-up task.
Why this matters
The local replication server is already good enough for reverse-engineering work. The canonical project should keep recording:
- what is running
- which schema owns which part of the application model
- which metadata tables are involved in menus, reports, selectors, and screen logic