Skip to content
Permalink
Browse files

FAQ: update some FAQ items (#938)

* update some FAQ items

* Update FAQ.md

Co-Authored-By: dcalvin <wenghao@pingcap.com>

* Update FAQ.md

Co-Authored-By: dcalvin <wenghao@pingcap.com>
  • Loading branch information...
dcalvin committed Mar 13, 2019
1 parent 47f4176 commit e08ee4188069a96fafddb4f173a4739b6a6bf985
Showing with 7 additions and 5 deletions.
  1. +7 −5 FAQ.md
12 FAQ.md
@@ -649,13 +649,15 @@ WAL belongs to ordered writing, and currently, we do not apply a unique configur
- NUMA: no specific suggestion; for memory allocation strategy, you can use `interleave = all`
- File system: ext4

#### How is the write performance in the most strict data available mode of `sync-log = true`?
#### How is the write performance in the most strict data available mode (`sync-log = true`)?

Generally, enabling `sync-log` reduces about 30% of the performance. For the test about `sync-log = false`, see [Performance test result for TiDB using Sysbench](benchmark/sysbench.md).
Generally, enabling `sync-log` reduces about 30% of the performance. For write performance when `sync-log` is set to `false`, see [Performance test result for TiDB using Sysbench](benchmark/sysbench.md).

#### Can the Raft + multiple replicas in the upper layer implement complete data security? Is it required to apply the most strict mode to standalone storage?
#### Can Raft + multiple replicas in the TiKV architecture achieve absolute data security? Is it necessary to apply the most strict mode (`sync-log = true`) to a standalone storage?

Raft uses strong consistency, and only when the data has been written into more than 50% of the nodes, the application returns ACK (two out of three nodes). In this case, data consistency is guaranteed. However, theoretically, two nodes might crash. Therefore, for scenarios that have a strict requirement on data security, such as scenarios in financial industry, you need to enable the `sync-log`.
Data is redundantly copied between TiKV nodes using the [Raft consensus algorithm](https://raft.github.io/) to ensure recoverability should a node failure occur. Only when the data has been written into more than 50% of the nodes, will the application return ACK (two out of three nodes). However, theoretically, two nodes might crash. Therefore, for scenarios with a strict requirement on data security, for example, the financial industry, you need to enable the `sync-log` mode.

As an alternative to using `sync-log`, you may also consider having five nodes instead of three in your Raft group. This would allow for the failure of two nodes, while still providing data safety.

#### In data writing using the Raft protocol, multiple network roundtrips occur. What is the actual write delay?

@@ -1094,4 +1096,4 @@ This error occurs when TiDB fails to access PD. A worker in the TiDB background

#### EOF error

When the client or proxy disconnects from TiDB, TiDB does not immediately notice that the connection has been disconnected. Instead, TiDB can only notice the disconnection when it begins to return data to the connection. At this time, the log prints an EOF error.
When the client or proxy disconnects from TiDB, TiDB does not immediately notice that the connection has been disconnected. Instead, TiDB can only notice the disconnection when it begins to return data to the connection. At this time, the log prints an EOF error.

0 comments on commit e08ee41

Please sign in to comment.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.