Add doc page on Redis #1015
Add doc page on Redis #1015
Conversation
Start by moving the existing content from the infrastructure page.
Make this distinctively about minor maintenance tasks and set expectations.
The rename is apparent on the add-on page, presumably because of the shift to using Valkey with version 7.2.¹ ¹ https://devcenter.heroku.com/changelog-items/2918
Start by copying steps from 5 → 6 upgrade notes¹ and adding some introductory text. ¹ https://github.com/tsibley/blab-standup/blob/17eb1690b70ca25aa7be7526b7e140e43cf0a1e6/2023-02-17.md
Reduce the amount of first-person wording which made sense for the note form, but not so much in a proper guide.
This can be detected automatically. The same can likely be done with the new instance name (to replace redis-X-N), but I don't want to create a new instance to test this at the moment.
This is necessary to test session restoration.
nextstrain-bot
temporarily deployed
to
nextstrain-s-victorlin--pt6y6j
|
Not ready to be merged, but the content (GitHub preview) is ready for review. I'll wait until after doing the 6.2→7.2 upgrade to see if there are any additional details to include before merging. |
| as all data looks to be transferred. Do this by entering Redis CLI (`heroku | ||
| redis:cli`) on both instances and comparing the output of: |
There was a problem hiding this comment.
heroku redis:cli used to not connect over TLS, which was bonkers, so for a long time I've used my own little program wrapping the Heroku CLI and standard Redis CLI.
But I just checked again now, and at least as of heroku version
heroku/7.60.2 linux-x64 node-v14.19.0
it does indeed connect over TLS.
I think if you want to use more advanced features of the Redis CLI, you'll still need to invoke it yourself directly (heroku redis:cli --help doesn't indicate it will pass thru any args), but it's nice that for a simple REPL you can just use heroku redis:cli now.
| - [`scan`](https://redis.io/docs/latest/commands/scan/) (start with `scan 0` | ||
| and follow the cursor a couple times) | ||
| - a manually issued [`sync`](https://redis.io/docs/latest/commands/sync/) jumping over bulk sync and right to live monitor |
There was a problem hiding this comment.
| - [`scan`](https://redis.io/docs/latest/commands/scan/) (start with `scan 0` | |
| and follow the cursor a couple times) | |
| - a manually issued [`sync`](https://redis.io/docs/latest/commands/sync/) jumping over bulk sync and right to live monitor | |
| - [`scan`](https://valkey.io/commands/scan/) (start with `scan 0` | |
| and follow the cursor a couple times) | |
| - a manually issued [`sync`](https://valkey.io/commands/sync/) jumping over bulk sync and right to live monitor |
| > [!NOTE] | ||
| > Heroku provides an [in-place upgrade | ||
| > method](https://devcenter.heroku.com/articles/heroku-redis-version-upgrade#upgrade-using-redis-upgrade) | ||
| > that is much simpler than the steps below. However, there is no option to roll | ||
| > back in case anything unexpected happens. If we find ourselves going through | ||
| > this process more often without any failures and this becomes too tedious, it | ||
| > may be worth switching to use the in-place upgrade method. |
There was a problem hiding this comment.
Linking back to our discussion of the tradeoffs here (https://github.com/nextstrain/private/issues/121#issuecomment-2330682764) will probably be helpful in the future.
previews: GitHub, RTD
Description of proposed changes
Preparing for upgrade (https://github.com/nextstrain/private/issues/121)
Currently, the GitHub markdown preview reflects my intentions. I might convert to RST instead so things render nicely on RTD.
Checklist