alexey.rassokhin/tet123
1
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Wiki Activity

DBZ-1371 README updates

Browse Source
This commit is contained in:
Gunnar Morling 2019-07-09 10:12:41 +02:00
parent 8c5d5021f4
commit 50e3a02d4d
2 changed files with 11 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
README.md
View File

@ -121,7 +121,12 @@ Look for references to the types defined in `io.debezium.connector.postgresql.De
$ mvn clean install -pl debezium-connector-postgres -Pwal2json-decoder \
-Ddocker.skip.build=true -Ddocker.skip.run=true -Dpostgres.host=<your PG host> \
-Dpostgres.user=<your user> -Dpostgres.password=<your password>
-Dpostgres.user=<your user> -Dpostgres.password=<your password> \
-Ddebezium.test.records.waittime=10
Adjust the timeout value as needed.
See [PostgreSQL on Amazon RDS](debezium-connector-postgres/RDS.md) for details on setting up a database on RDS to test against.
## Contributing

12
debezium-connector-postgres/README.md
View File

@ -4,7 +4,7 @@ This module defines the connector that ingests change events from PostgreSQL dat
## Using the PostgreSQL connector with Kafka Connect
The PostgreSQL connector is designed to work with [Kafka Connect](http://kafka.apache.org/documentation.html#connect) and to be deployed to a Kafka Connect runtime service. The deployed connector will monitor one or more schemas within a database server
The PostgreSQL connector is designed to work with [Kafka Connect](http://kafka.apache.org/documentation.html#connect) and to be deployed to a Kafka Connect runtime service. The deployed connector will monitor one or more schemas within a database server
and write all change events to Kafka topics, which can be independently consumed by one or more clients. Kafka Connect can be distributed to provide fault tolerance to ensure the connectors are running and continually keeping up with changes in the database.
Kafka Connect can also be run standalone as a single process, although doing so is not tolerant of failures.
@ -19,9 +19,9 @@ This module contains both unit tests and integration tests.
A *unit test* is a JUnit test class named `*Test.java` or `Test*.java` that never requires or uses external services, though it can use the file system and can run any components within the same JVM process. They should run very quickly, be independent of each other, and clean up after itself.
An *integration test* is a JUnit test class named `*IT.java` or `IT*.java` that uses a PostgreSQL database server running in a custom Docker container based upon the [debezium/postgres:9.6](https://github.com/debezium/docker-images/tree/master/postgres/9.6) Docker image maintained by the Debezium team.
This docker image uses a default PostgreSQL 9.6 image on top of which it installs the [Debezium Logical Decoding plugin](https://github.com/debezium/postgres-decoderbufs) which is required in order to be able to receive database events.
The build will automatically start the PostgreSQL container before the integration tests are run and automatically stop and remove it after all of the integration tests complete (regardless of whether they succeed or fail).
An *integration test* is a JUnit test class named `*IT.java` or `IT*.java` that uses a PostgreSQL database server running in a custom Docker container based upon the [debezium/postgres:9.6](https://github.com/debezium/docker-images/tree/master/postgres/9.6) Docker image maintained by the Debezium team.
This docker image uses a default PostgreSQL 9.6 image on top of which it installs the [Debezium Logical Decoding plugin](https://github.com/debezium/postgres-decoderbufs) which is required in order to be able to receive database events.
The build will automatically start the PostgreSQL container before the integration tests are run and automatically stop and remove it after all of the integration tests complete (regardless of whether they succeed or fail).
Running `mvn install` will compile all code and run the unit and integration tests. If there are any compile problems or any of the unit tests fail, the build will stop immediately. Otherwise, the command will continue to create the module's artifacts, create the Docker image with PostgreSQL and custom scripts, start the Docker container, run the integration tests, stop the container (even if there are integration test failures), and run checkstyle on the code. If there are still no problems, the build will then install the module's artifacts into the local Maven repository.
@ -39,8 +39,6 @@ Of course, wildcards also work:
These commands will automatically manage the PostgreSQL Docker container.
If you want to run the test suite against an Amazon RDS PostgreSQL environment, see [PostgreSQL on Amazon RDS](https://github.com/debezium/debezium/blob/master/debezium-connector-postgres/RDS.md) for details.
### Debugging tests
If you want to debug integration tests by stepping through them in your IDE, using the `mvn install` command will be problematic since it will not wait for your IDE's breakpoints. There are ways of doing this, but it is typically far easier to simply start the Docker container and leave it running so that it is available when you run the integration test(s). The following command:
@ -74,4 +72,4 @@ Sometimes you may want to inspect the state of the database(s) after one or more
This instructs Maven to run the normal Maven lifecycle through `integration-test`, and to stop before the `post-integration-test` phase when the Docker container is normally shut down and removed. Be aware that you will need to manually stop and remove the container before running the build again:
$ mvn docker:stop
$ mvn docker:stop