The first commit to NodeBB was nearly four years ago, and in that time, many changes have been made to the core code itself, from feature additions and bug fixes, to bundling of must-have plugins for all installations.
As with any code that matures, schema changes needed to be made over time to ensure that stored data was kept in an ideal manner, so as to reduce the use of anti-patterns such as god tables and XYZ. The second reason schema changes are made are due to revisions in the original implementation. Perhaps a design decision from before could have been done in a more efficient way, and that may need a migration of active data from one data type to another (e.g. a list to a sorted set).
Yep, we jumped a minor version because there are a number of breaking changes. Technically, if there are breaking changes, we should increment a major version number, but after lengthy internal discussion, we felt that such a jump (from v1.0.3 to v2.0.0) would incorrectly signify that a whole bunch of things had changed, when this was really more of a "maintenance patch + a bunch of new features" release.
Binding a port through your ssh connection is actually quite simple.
(The following assumes that you are using the OpenSSH client on GNU/Linux)
Access remote redis-server with Redis Desktop Manager via SSH
Start the SSH client with ssh email@example.com -L 7000:localhost:6379
So basically like you would normally do, appending -L ... with the syntax:
local_port:interface_on_remote:remote_port (ssh manpage)
You should have an interactive session to your remote, prompt and all or whatever your setup resolves into when logging in over SSH. Again, business as usual is expected here.
Now comes the good part: Since you tunneled your local port 7000 to the remotes localhost interface on (redis-) port 6379, you can create a new connection in Redis Desktop Manager, ignoring the SSH tab in the "New Connection" dialog and simply connecting to localhost:7000.
Today's article will be a short how-to guide regarding a common problem with horizontally scaled NodeBB installations:
In a deployment environment with more than one NodeBB server, locally uploaded files (post images, avatars, etc) are split between the application servers, and n-1/n images will always be missing, where n is the number of servers