New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translog: Implement a file system based translog and make it the default #260
Comments
Translog: Implement a file system based translog and make it the default, closed by 95ba62f. |
williamrandolph
pushed a commit
to williamrandolph/elasticsearch
that referenced
this issue
Jun 4, 2020
Change Tap and Sink mode to UPDATE since it seems that CascadingConnector will try to delete them otherwise resulting in exceptions Fix elastic#260
williamrandolph
pushed a commit
to williamrandolph/elasticsearch
that referenced
this issue
Jun 4, 2020
mindw
pushed a commit
to mindw/elasticsearch
that referenced
this issue
Sep 5, 2022
…lastic#260) MPC-3074: remove media-manager UI elements [DRAFT] * first pass at remove media-manager UI elements * remove media-manager webapp from rc.local * more cleaning passes uncovering more pieces to clean * use `npm version` for media-manager * deleting files as per review Approved-by: Gideon Avida Approved-by: Can Yildiz
cbuescher
pushed a commit
to cbuescher/elasticsearch
that referenced
this issue
Oct 2, 2023
With this commit we add a new parameter `placement` in the race config file that allows to specify per track which benchmark machine should be targeted when the number of targeted machines is less than the number of available ones. The motivation for this change is that single-node benchmarks have historically always targeted the first machine in the pool leading to frequent disk failures. If we spread the load across machines the expected lifetime of the disks across machines is more evenly distributed. By only allowing to specify the placement on the top level (i.e. per track) we ensure that charts for the same track are still consistent and don't suffer from machine to machine variation. In this commit we also modify the race configurations for the existing nightly benchmarks. We have assigned the placement roughly based on the expected write load. It is not possible to spread the load completely evenly because some tracks dominate I/O load (for example `nyc_taxis` for group-1) but spreading the load a bit is still preferable to have the disk on the first target machine always fail first. Relates elastic#259
emilykmarx
pushed a commit
to emilykmarx/elasticsearch
that referenced
this issue
Dec 26, 2023
Allows the user to configure network timeouts to Elasticsearch. Default is the previous behavior: no timeout As part of this, I added some documentation for the `build_client` method to describe the parameters. For elastic#260
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, there is an on going in memory translog (per shard) holding all the operations done between flushes. There is a memory monitor to control if there are memory problems and then do a flush to clean it (on the most expensive shards) as well as auto flush each N (5000) number of operations. Still, this memory can be of good use other than the translog.
A file system based translog will hold the changes on a file. There is no need to flush / fsync it since its not really used for full shutdown recovery (the gateway is there for that) so it should be fast enough.
It should be used as the default as well for better out of the box experience.
The text was updated successfully, but these errors were encountered: