init cdc codes from tiflow/[email protected] (#41)

* init cdc codes from tiflow/[email protected]

Signed-off-by: zeminzhou <[email protected]>

* init br codes from tiflow/[email protected]

Signed-off-by: zeminzhou <[email protected]>

* fix the DCO

Signed-off-by: zeminzhou <[email protected]>

* remove test.txt

Signed-off-by: zeminzhou <[email protected]>

br/.codecov.yml

@@ -0,0 +1,22 @@
+codecov:
+  require_ci_to_pass: yes
+
+comment:
+  layout: "reach, diff, flags, files"
+  behavior: default
+  require_changes: false  # if true: only post the comment if coverage changes
+  require_base: no        # [yes :: must have a base report to post]
+  require_head: yes       # [yes :: must have a head report to post]
+  branches:               # branch names that can post comment
+    - "master"
+
+coverage:
+  status:
+    project:
+      default:
+        # Allow the coverage to drop by 3%
+        target: 85%
+        threshold: 3%
+        branches:
+          - master
+    patch: off

br/.dockerignore

@@ -0,0 +1 @@
+.gitignore

br/.editorconfig

@@ -0,0 +1,10 @@
+[*]
+end_of_line = lf
+insert_final_newline = true
+charset = utf-8
+
+# tab_size = 4 spaces
+[*.go]
+indent_style = tab
+indent_size = 4
+trim_trailing_whitespace = true

br/.gitattributes

@@ -0,0 +1 @@
+*_generated.go linguist-generated=true

br/.gitignore

@@ -0,0 +1,14 @@
+/br
+/bin
+/.idea
+/docker/data/
+/docker/logs/
+*.swp
+.DS_Store
+/go.mod
+/go.sum
+
+# for the web interface
+web/node_modules/
+web/dist/
+.vscode/

br/.golangci.yml

@@ -0,0 +1,12 @@
+linters-settings:
+  gocyclo:
+    min-complexity: 40
+
+issues:
+  # Excluding configuration per-path, per-linter, per-text and per-source
+  exclude-rules:
+    # TODO Remove it.
+    - path: split_client.go
+      text: "SA1019:"
+      linters:
+        - staticcheck

br/COMPATIBILITY_TEST.md

@@ -0,0 +1,42 @@
+# Compatibility test
+
+## Background
+
+We had some incompatibility issues in the past, which made BR cannot restore backed up data in some situations.
+So we need a test workflow to check the compatiblity.
+
+## Goal
+
+- Ensure backward compatibility for restoring data from the previous 3 minor versions
+
+## Workflow
+
+### Data Preparation
+
+This workflow needs previous backup data. To get this data. we perform the following steps
+
+- Run a TiDB cluster with previous version.
+- Run backup jobs with corresponding BR version, with different storages (s3, gcs).
+
+Given we test for the previous 3 versions, and there are 2 different storage systems, we will produce 6 backup archives for 6 separate compatibility tests.
+
+### Test Content
+
+- Start TiDB cluster with nightly version.
+- Build BR binary with current directory.
+- Use BR to restore different version backup data one by one.
+- Make sure restore data is expected.
+
+### Running tests
+
+Start a cluster with docker-compose and Build br with latest version.
+
+```sh
+docker-compose -f docker-compose.yaml rm -s -v && \
+docker-compose -f docker-compose.yaml build && \
+docker-compose -f docker-compose.yaml up --remove-orphans
+```
+
+```sh
+docker-compose -f docker-compose.yaml control make compatibility_test
+```

br/CONTRIBUTING.md

@@ -0,0 +1,90 @@
+# How to contribute
+
+This document outlines some of the conventions on development workflow, commit
+message formatting, contact points and other resources to make it easier to get
+your contribution accepted.
+
+## Getting started
+
+- Fork the repository on GitHub.
+- Read the README.md for build instructions.
+- Play with the project, submit bugs, submit patches!
+
+## Building BR
+
+Developing BR requires:
+
+* [Go 1.16+](http://golang.org/doc/code.html)
+* An internet connection to download the dependencies
+
+Simply run `make` to build the program.
+
+```sh
+make
+```
+
+### Running tests
+
+This project contains unit tests and integration tests with coverage collection.
+See [tests/README.md](./tests/README.md) for how to execute and add tests.
+
+### Updating dependencies
+
+BR uses [Go 1.11 module](https://github.com/golang/go/wiki/Modules) to manage dependencies.
+To add or update a dependency: use the `go mod edit` command to change the dependency.
+
+## Contribution flow
+
+This is a rough outline of what a contributor's workflow looks like:
+
+- Create a topic branch from where you want to base your work. This is usually `master`.
+- Make commits of logical units and add test case if the change fixes a bug or adds new functionality.
+- Run tests and make sure all the tests are passed.
+- Make sure your commit messages are in the proper format (see below).
+- Push your changes to a topic branch in your fork of the repository.
+- Submit a pull request.
+- Your PR must receive LGTMs from two maintainers.
+
+Thanks for your contributions!
+
+### Code style
+
+The coding style suggested by the Golang community is used in BR.
+See the [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details.
+
+Please follow this style to make BR easy to review, maintain and develop.
+
+### Format of the Commit Message
+
+We follow a rough convention for commit messages that is designed to answer two
+questions: what changed and why. The subject line should feature the what and
+the body of the commit should describe the why.
+
+```
+restore: add comment for variable declaration
+
+Improve documentation.
+```
+
+The format can be described more formally as follows:
+
+```
+<subsystem>: <what changed>
+<BLANK LINE>
+<why this change was made>
+<BLANK LINE>
+<footer>(optional)
+```
+
+The first line is the subject and should be no longer than 70 characters, the
+second line is always blank, and other lines should be wrapped at 80 characters.
+This allows the message to be easier to read on GitHub as well as in various
+git tools.
+
+If the change affects more than one subsystem, you can use comma to separate them like `backup,restore:`.
+
+If the change affects many subsystems, you can use ```*``` instead, like ```*:```.
+
+For the why part, if no specific reason for the change,
+you can use one of some generic reasons like "Improve documentation.",
+"Improve performance.", "Improve robustness.", "Improve test coverage."