This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-22
Channels
- # announcements (39)
- # architecture (9)
- # aws (2)
- # babashka (17)
- # beginners (73)
- # calva (6)
- # cider (27)
- # clj-kondo (140)
- # cljdoc (67)
- # cljsrn (1)
- # clojure (99)
- # clojure-dev (4)
- # clojure-europe (35)
- # clojure-nl (7)
- # clojure-spec (19)
- # clojure-uk (2)
- # clojurescript (40)
- # community-development (3)
- # cursive (10)
- # datalevin (2)
- # datavis (2)
- # datomic (27)
- # deps-new (5)
- # events (2)
- # fulcro (38)
- # integrant (6)
- # jobs (3)
- # keyboards (1)
- # leiningen (13)
- # lsp (3)
- # malli (10)
- # meander (5)
- # membrane (1)
- # membrane-term (9)
- # missionary (3)
- # off-topic (29)
- # polylith (3)
- # reagent (3)
- # reitit (5)
- # remote-jobs (2)
- # reveal (7)
- # shadow-cljs (20)
- # tools-build (4)
- # tools-deps (8)
- # vim (10)
- # xtdb (3)
looking for my cloud system endpoint, when I do aws cloudformation describe-stacks --stack-name <name>
the only output that sounds like endpoint is this:
{
"OutputKey": "EndpointAddress",
"OutputValue": "",
"Description": "Stable entry address"
},
That outputvalue
is your endpoint. You can also see your system endpoint https://docs.datomic.com/cloud/operation/howto.html#template-outputsunder the outputs tab. Specifically under the ClientApiGatewayEndpoint
key. As a side curiosity, what version of Datomic Cloud are you using?
should be the newest I selected from the top of the list in the marketplace configure
@U02CV2P4J6S If you are looking to upgrade. Might I suggest that you use our split stack instructions and move to separate production templates on the latest. https://docs.datomic.com/cloud/operation/split-stacks.html.
The https://docs.datomic.com/cloud/changes.html#936-9118 allows you to choose smaller instances to get the lower price of the "solo" template when we had the bifurcation. Marketplace does not allow us to remove the option for any users who were previously subscribed to select the solo topology even though it is now moot.
I see. Now I already launched a production on next to the solo one. Guess I check the split thing
Yeah I think you should upgrade to the production template and follow our docs, reading https://docs.datomic.com/cloud/changes.html+ split stack page. I'd be happy to jump on a call to discuss.
If you don't care about anything you made with the solo, I can also walk you through completely deleting.
Dear Cognitect Datomic team, here's a renewed plea for a production-grade Datomic Cloud Backup & Restore solution. Here we relied on the nice efforts by Tony Kay with some success, but we now see our fate is truly and only in your hands.
btw we use this for datomic cloud backups https://github.com/lambdaforge/wanderung
we actually wrap it in another, our ops-specific tool that does some other niceties like opening datomic-cloud proxies from dev machines: https://gitlab.com/arbetsformedlingen/taxonomy-dev/backend/jobtech-taxonomy-api-gitops/-/blob/master/src/jobtech_taxonomy_api_gitops/database.clj#L239
Thanks vlaaad. Wanderung is intriguing, and it's nice to have your gitops util to look at.
Do you feel like it satisfies all normal requirements? E.g. • truly coherent remapping of IDs (obviously) in the new DB • capability to clean up PII when restoring to a non-prod DB
I think @UB95JRKM3 might provide more insight into this. What do you mean by coherent remapping?
db ids are different between backups/restores, but they represent the same data graphs
our datomic usage is a bit weird, since we use it as a "git" of sorts with history being a part of publicly exposed API (although wrapped so customer don't know about db ids and txs)
because of that, we have separate databases for edits and what is available to users in prod, and we copy and restore them between internal edits and prod read-only dbs, so we actively use the copying/restoring feature, and so far it seems to work fine
Same repo has tools for rewriting history as well https://gitlab.com/arbetsformedlingen/taxonomy-dev/backend/jobtech-taxonomy-api-gitops/-/blob/master/src/jobtech_taxonomy_api_gitops/database.clj#L254
one thing to be aware of is that we can afford to hold all datoms in memory, so it might not be optimized for backups of big databases...
Ok, you answered all the questions I had (including DB id coherency). Thanks again!
Thanks for letting us know, Stu! 🎉
@U072WS7PE what would be really nice is some kind of time estimate. Some of us have regulators to satisfy, and “it will happen sometime in the future” is not a comfortable position to be in.