Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a number of nodes each owning a subset of a large pool of physical resources. Each node only handles it's own resources but needs to do so based on the state of all resources in the pool.
A node only updates the state of it's own resources but listens to state changes of all the others.
When a node dies (process terminated, crash, power loss,...) those physical resources die with it and the other nodes must discard them ASAP.
Now i would do this with a distributed replicated cache (so nodes can read the local replicas for performance), but how to "clear" deceases entries (the owning node can't do it).
Standard answer seems to be Expiry policy = map entry gets X seconds to live without update, then gone. Problem is, if you are thinking in the 100.000 range of resources and 100 nodes, that is a LOT of updates to send everywhere for NOT changing state. Not to mention the work to update each entry before the timeout and discard these updates in the other nodes.
Any better way of doing this?
Subscribe to EVT_NODE_LEFT via IgniteEvents
Find related entries via SqlQuery or ScanQuery and remove them
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 months ago.
Improve this question
Let's say we are running some services in a Kubernetes cluster and one of them requires a PostgreSQL instance, expected to persist data reliably. Should the DB live in the cluster or be configured separately?
Imagine that the DB is deployed in the cluster. This probably means one of the following:
We need a process for migrating the data to another node in case the current one goes down. This sounds like a non-trivial task. Or:
The node where the DB lives has to be treated in a special way. Horizontal scaling must be constrained to the other nodes and the cluster ceases to be homogeneous. This might be seen as a design flaw, going against the spirit of maintaining disposable, replaceable containers.
Point (1) applies only to self-managed clusters where all the storage we have at our disposal is tied to machines where the nodes run. If we are using a managed cloud, we can use persistent volume claims and a new instance can pick up the data automatically. Still, this means that if the node with the DB is removed, we will suffer a database downtime until a new instance comes up. So point (2) remains valid also for managed K8s offerings.
Therefore I can well understand the argument for keeping the DB outside of Kubernetes. What would some counterarguments look like? There are a lot of official helm charts for various DBs which suggests that people keep their DBs in Kubernetes clusters after all.
Happy to learn some critical thoughts!
This is not an anti-pattern. It is just difficult to implement and manage.
Point 1
In a self hosted cluster also you can have persistent volume storage provisioned though GlusterFS and CEPH. So, you don't always have to use ephemeral storage. So, Point 1 is not fully valid.
The DBs are generally created as a statefulsets, where every instance gets its own copy of data.
Point 2
When your DB cluster horizontally scales, the 'init' container of the new DB pod or a CRD provided by the DB needs to register the 'secondary' DB pod so it becomes the part of your dB cluster
A statefulset needs to also run as a headless service so the IPs of each endpoint is also known all the time for cluster healthcheck and primary->secondary data sync and to elect a new primary selection in case the primary node goes down
So, as long as the new pods register themselves to the DB cluster, you will be okay to run your db workload inside a kubernetes cluster
Further reading: https://devopscube.com/deploy-postgresql-statefulset/
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
This post was edited and submitted for review 1 year ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
When should you consider disabling auto-suspend for a Virtual Warehouse?
A. When users will be using compute at different times throughout a 24/7 period
B. When managing a steady workload
C. When the compute must be available with no delay or lag time
D. When you don’t want to have to manually turn on the Warehouse each time a user needs it
If we have to choose 2 options "B" is perfect but how about from "C" or "D" ?
The most common reason to disable auto-suspend is in situations where you don't want to lose the cache that exists on the warehouse, which would add additional query time to the first few queries that are executed after a warehouse resumes. In essence, when query time is critical and must be consistent, you'd potentially want to disable auto-suspend and allow the warehouse to stay up and running (either 24/7 or during a specified time period - using a task to suspend or resume the warehouse explicitly).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
For pubsub topics with number of messages in the range of ~100k, what is the best practice for draining/dropping/clearing/deleting all messages using gcloud-java SDK?
Possible solutions:
Deleting and recreating the subscribers and then the publishers
High concurrency pull+ack (easy to hit the quota this way)
Something else
My hope is that this process can be fast (not more than ~60 seconds, say), robust, and uses supported SDK methods with minimal other code.
Update with description of snapshot and seek feature:
One can use seek on a Pub/Sub subscription to ack older messages by seeking to a timestamp corresponding to now. The best way is via the gcloud command line tool. The command to acknowledge messages published up to a particular timestamp would be:
gcloud pubsub subscriptions seek <subscription path> --time=yyyy-mm-ddThh:mm:ss
To delete all messages up to now:
gcloud pubsub subscriptions seek <subscription path> --time=$(date +%Y-%m-%dT%H:%M:%S)
Previous answer prior to the addition of snapshot and seek:
Currently, Google Cloud Pub/Sub has no way clear older messages, though it is something we are looking to add. Deleting and recreating the subscription would be the most efficient way to clear it, both in terms of time and cost. You wouldn't have to do anything with your publishers; any messages published from the point after recreation on will be sent to subscribers on the recreated subscription.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm struggling to find a solution for the following issue:
Let's say I have a 'server' process in Kernel that centralize reports from all 'client' processes that signed up on it. This 'server' process will report other CPUs in the system when all 'client' processes finished their boot and they are ready.
A 'client' in my example will be any process in my system that wish to sign as one that 'server' needs to wait until he'll finish booting.
My problem is that the entire process above most be done in build time, because otherwise I am vulnerable to race cases, such as the following example:
Let's say my 'server' process finished his initial boot and he is ready, and he was the first process to boot in the system. In that case, if another CPU will query him - he will response that all 'clients' are ready (even if no one listed). So when other 'clients' will boot and list on it - it will be too late.
I want to build a generic solution, so once I finished building my environment - the 'server' process will 'know' how many 'clients' should sign up during system boot.
Any ideas here?
Thank you all
Here is what I have understood:
you want to build a service that will report whether other clients are up or not
you want the list of clients to be dynamic - ie a client could register or unregister at will
you want the list of clients to be persistent - the service should know the current list of clients immediately after each boot
A common way for that kind of requirement is to use a persistent database where the client can register (add one line) or unregister (delete their own line). The service has then only to read the database at boot time or on each request.
You cant then decide :
whether you want to use a simple file, a lite database (SQLite) or a full database (PosgreSQL, MariaDB, ...)
whether you want to read the database on each and every query or have the server cache the current state
in case of caching, whether you can accept non accurate responses, and just refresh state when it is older than n seconds, or if you need immediate synchronization (database is read at boot, but registration goes to service that writes database back to persistent storage) - that last way is more accurate but registration is only possible when service is up
Depending on you actual requirements, you can then imagine more clever solutions, but above should help you to start
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Currently using boltdb for storing various entries in the bucket.
How can I use goroutines and channels in reading and updating in the db?
Generally, yes you can, provided you pay attention to the following points:
all accesses should be done in their own transactions. Transactions should not be shared between goroutines (whether they are read-only or read-write).
boltdb only tolerates one writer at a given point in time. If multiple concurrent transactions try to write at the same time, they will be serialized. The consistency of the database is guaranteed, but it has an impact on the performance, since write operations cannot be parallelized.
read-only transactions are executed concurrently (and potentially parallelized).
open only one transaction in a given goroutine at the same time to avoid deadlock situations.