Frequently Asked Question

    The following is true for users on Badger v1.x.

    This can happen if a long running iteration with Prefetch is set to false, but a Item::Value call is made internally in the loop. That causes Badger to acquire read locks over the value log files to avoid value log GC removing the file from underneath. As a side effect, this also blocks a new value log GC file from being created, when the value log file boundary is hit.

    Please see Github issues and #315.

    There are multiple workarounds during iteration:

    1. Use Item::ValueCopy instead of Item::Value when retrieving value.
    2. Set Prefetch to true. Badger would then copy over the value and release the file lock immediately.
    3. When Prefetch is false, don’t call Item::Value and do a pure key-only iteration. This might be useful if you just want to delete a lot of keys.
    4. Do the writes in a separate transaction after the reads.

    My writes are really slow. Why?

    Are you creating a new transaction for every single key update, and waiting for it to Commit fully before creating a new one? This will lead to very low throughput.

    We have created WriteBatch API which provides a way to batch up many updates into a single transaction and Commit that transaction using callbacks to avoid blocking. This amortizes the cost of a transaction really well, and provides the most efficient way to do bulk writes.

    Note that WriteBatch API does not allow any reads. For read-modify-write workloads, you should be using the API.

    I don’t see any disk writes. Why?

    If you’re using Badger with SyncWrites=false, then your writes might not be written to value log and won’t get synced to disk immediately. Writes to LSM tree are done inmemory first, before they get compacted to disk. The compaction would only happen once MaxTableSize has been reached. So, if you’re doing a few writes and then checking, you might not see anything on disk. Once you Close the database, you’ll see these writes on disk.

    Just like forward iteration goes to the first key which is equal or greater than the SEEK key, reverse iteration goes to the first key which is equal or lesser than the SEEK key. Therefore, SEEK key would not be part of the results. You can typically add a 0xff byte as a suffix to the SEEK key to include it in the results. See the following issues: and #347.

    Which instances should I use for Badger?

    I’m getting a closed channel error. Why?

    1. panic: close of closed channel
    2. panic: send on closed channel

    If you’re seeing panics like above, this would be because you’re operating on a closed DB. This can happen, if you call Close() before sending a write, or multiple times. You should ensure that you only call Close() once, and all your read/write operations finish before closing.

    We highly recommend setting a high number for GOMAXPROCS, which allows Go to observe the full IOPS throughput provided by modern SSDs. In Dgraph, we have set it to 128. For more details, .

    Are there any Linux specific settings that I should use?

    We recommend setting max file descriptors to a high number depending upon the expected size of your data. On Linux and Mac, you can check the file descriptor limit with ulimit -n -H for the hard limit and for the soft limit. A soft limit of 65535 is a good lower bound. You can adjust the limit as needed.

    I see “manifest has unsupported version: X (we support Y)” error.

    This error means you have a badger directory which was created by an older version of badger and you’re trying to open in a newer version of badger. The underlying data format can change across badger versions and users will have to migrate their data directory. Badger data can be migrated from version X of badger to version Y of badger by following the steps listed below. Assume you were on badger v1.6.0 and you wish to migrate to v2.0.0 version.

    1. Install badger version v1.6.0

      • git checkout v1.6.0

      • cd badger && go install

        This should install the old badger binary in your $GOBIN.

      • badger backup --dir path/to/badger/directory -f badger.backup

    3. Install badger version v2.0.0

      • cd $GOPATH/src/github.com/dgraph-io/badger

      • git checkout v2.0.0

      • cd badger && go install

        This should install new badger binary in your $GOBIN

    NOTE - The above steps shouldn’t cause any data loss but please ensure the new data is valid before deleting the old badger directory.