-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Option to start without migration? #30
Comments
Not sure if I understand the use case correctly. Are you running Redka on the read-only database replica? Do you plan to only use API methods like Get, and not methods like Set or Delete? |
Yes, when a cluster of Go binaries are up, the leader will be granted read-write access, while all the replicas will be in read-only. The LiteFS package intercepts all sqlite operations to handle this. Having checked through the API of Redka again, I realise it would additionally require modifying the Similarly, if a leader is changed (via consensus) then that will now be promoted to perform read & writes. This is not something I considered before making the issue, and so unsure if this can be achieved without injecting very LiteFS specific code (they offer a way for a node to know if its a parent, but I'd expect this is not something that could be added to a general purpose library), so something I need to rethink. Here is an example project on Fly's profile using the standard |
Regarding needing to know if a DB has been promoted, if the logic could be in application space and either an atomic value or a public field can be dynamically updated, then this could allow the application to run a go routine to look for these changes, reducing the work this library would need to do. // pseudo-code
go func () {
// user will look for changes in the filesystem
// can be accomplished with an interval or hooking into litefs events
// but this would be all within application space, not the library
isPrimary, _ := nodeIsPrimary(ctx)
if isPrimary {
// modify the value.
// or modify a package level atomic value.
kv.Mode(redka.Write)
}
} () I do recognise this is niche & such a change needs to not break expectations for current users. |
I see, thanks for the detailed explanation! I'll think about it over the weekend and hopefully come back with something. |
Here is the proposed design:
db, err := redka.OpenRead("data.db", nil)
db.Close()
db, err := redka.Open("data.db", nil) What do you think? |
I think this could work, I have an example project setup with litefs that I can experiment with. To me, I should be able to open a go routine in Would this This would likely mean reassigning the |
Please try using
// open a writable database
db, err := redka.Open("data.db", nil)
if err != nil {
panic(err)
}
db.Str().Set("name", "alice")
db.Close()
// open a read-only database
db, err = redka.OpenRead("data.db", nil)
if err != nil {
panic(err)
}
// read operations work fine
name, _ := db.Str().Get("name")
fmt.Println(name)
// write operations will fail
err = db.Str().Set("name", "bob")
fmt.Println(err)
db.Close()
|
Any luck trying |
As the title suggests, would be interested if the API can be modified to allow users to open a connection and run the initial table creations separately.
The use-case is a tool such as LiteFS, a SQLite replication package. This currently limits one writer to the database on server creation. A problem arises with this package when spinning up a replica
2024-06-27 23:19:11 failed to create kv client: disk I/O error: permission denied 2024-06-27 23:19:11 level=INFO msg="E6A5861BC03876BC: disconnected from primary with error, retrying: next frame: context canceled"
This could likely be resolved by giving an option to ignore calling
sqlx.*DB[T].createSchema
pass by through theredka.Options
struct.A package level function could likely be exported instead to run the function:
giving a bit more flexibility to the application developer.
The text was updated successfully, but these errors were encountered: