Debezium connector for PostgreSQL
Debezium’s PostgreSQL connector captures row-level changes in the schemas of a PostgreSQL database. PostgreSQL versions 9.6, 10, 11, and 12 are supported.
The first time it connects to a PostgreSQL server or cluster, the connector takes a consistent snapshot of all schemas. After that snapshot is complete, the connector continuously captures row-level changes that insert, update, and delete database content and that were committed to a PostgreSQL database. The connector generates data change event records and streams them to Kafka topics. For each table, the default behavior is that the connector streams all generated events to a separate Kafka topic for that table. Applications and services consume data change event records from that topic.
Overview
PostgreSQL’s logical decoding feature was introduced in version 9.4. It is a mechanism that allows the extraction of the changes that were committed to the transaction log and the processing of these changes in a user-friendly manner with the help of an output plug-in. The output plug-in enables clients to consume the changes.
The PostgreSQL connector contains two main parts that work together to read and process database changes:
-
A logical decoding output plug-in. You might need to install the output plug-in that you choose to use. You must configure a replication slot that uses your chosen output plug-in before running the PostgreSQL server. The plug-in can be one of the following:
-
decoderbufs
is based on Protobuf and maintained by the Debezium community. -
wal2json
is based on JSON and maintained by the wal2json community. -
pgoutput
is the standard logical decoding output plug-in in PostgreSQL 10+. It is maintained by the PostgreSQL community, and used by PostgreSQL itself for logical replication. This plug-in is always present so no additional libraries need to be installed. The Debezium connector interprets the raw replication event stream directly into change events.
-
-
Java code (the actual Kafka Connect connector) that reads the changes produced by the chosen logical decoding output plug-in. It uses PostgreSQL’s streaming replication protocol, by means of the PostgreSQL JDBC driver
The connector produces a change event for every row-level insert, update, and delete operation that was captured and sends change event records for each table in a separate Kafka topic. Client applications read the Kafka topics that correspond to the database tables of interest, and can react to every row-level event they receive from those topics.
PostgreSQL normally purges write-ahead log (WAL) segments after some period of time. This means that the connector does not have the complete history of all changes that have been made to the database. Therefore, when the PostgreSQL connector first connects to a particular PostgreSQL database, it starts by performing a consistent snapshot of each of the database schemas. After the connector completes the snapshot, it continues streaming changes from the exact point at which the snapshot was made. This way, the connector starts with a consistent view of all of the data, and does not omit any changes that were made while the snapshot was being taken.
The connector is tolerant of failures. As the connector reads changes and produces events, it records the WAL position for each event. If the connector stops for any reason (including communication failures, network problems, or crashes), upon restart the connector continues reading the WAL where it last left off. This includes snapshots. If the connector stops during a snapshot, the connector begins a new snapshot when it restarts.
|
The connector relies on and reflects the PostgreSQL logical decoding feature, which has the following limitations:
Behavior when things go wrong describes what the connector does when there is a problem. |
|
Debezium currently supports databases with UTF-8 character encoding only. With a single byte character encoding, it is not possible to correctly process strings that contain extended ASCII code characters. |
How the connector works
To optimally configure and run a Debezium PostgreSQL connector, it is helpful to understand how the connector performs snapshots, streams change events, determines Kafka topic names, and uses metadata.
Snapshots
Most PostgreSQL servers are configured to not retain the complete history of the database in the WAL segments. This means that the PostgreSQL connector would be unable to see the entire history of the database by reading only the WAL. Consequently, the first time that the connector starts, it performs an initial consistent snapshot of the database. The default behavior for performing a snapshot consists of the following steps. You can change this behavior by setting the snapshot.mode
connector configuration property to a value other than initial
.
-
Start a transaction with a SERIALIZABLE, READ ONLY, DEFERRABLE isolation level to ensure that subsequent reads in this transaction are against a single consistent version of the data. Any changes to the data due to subsequent
INSERT
,UPDATE
, andDELETE
operations by other clients are not visible to this transaction. -
Obtain an
ACCESS SHARE MODE
lock on each of the tables being tracked to ensure that no structural changes can occur to any of the tables while the snapshot is taking place. These locks do not prevent tableINSERT
,UPDATE
andDELETE
operations from taking place during the snapshot.This step is omitted when
snapshot.mode
is set toexported
, which allows the connector to perform a lock-free snapshot. -
Read the current position in the server’s transaction log.
-
Scan the database tables and schemas, generate a
READ
event for each row and write that event to the appropriate table-specific Kafka topic. -
Commit the transaction.
-
Record the successful completion of the snapshot in the connector offsets.
If the connector fails, is rebalanced, or stops after Step 1 begins but before Step 6 completes, upon restart the connector begins a new snapshot. After the connector completes its initial snapshot, the PostgreSQL connector continues streaming from the position that it read in step 3. This ensures that the connector does not miss any updates. If the connector stops again for any reason, upon restart, the connector continues streaming changes from where it previously left off.
|
It is strongly recommended that you configure a PostgreSQL connector to set |
| Setting | Description |
|---|---|
|
The connector always performs a snapshot when it starts. After the snapshot completes, the connector continues streaming changes from step 3 in the above sequence. This mode is useful in these situations:
|
|
The connector never performs snapshots. When a connector is configured this way, its behavior when it starts is as follows. If there is a previously stored LSN in the Kafka offsets topic, the connector continues streaming changes from that position. If no LSN has been stored, the connector starts streaming changes from the point in time when the PostgreSQL logical replication slot was created on the server. The |
|
The connector performs a database snapshot and stops before streaming any change event records. If the connector had started but did not complete a snapshot before stopping, the connector restarts the snapshot process and stops when the snapshot completes. |
|
The connector performs a database snapshot based on the point in time when the replication slot was created. This mode is an excellent way to perform a snapshot in a lock-free way. |
|
The |
Custom snapshotter SPI
For more advanced uses, you can provide an implementation of the io.debezium.connector.postgresql.spi.Snapshotter
interface. This interface allows control of most of the aspects of how the connector performs snapshots. This includes whether or not to take a snapshot, the options for opening the snapshot transaction, and whether to take locks.
Following is the full API for the interface. All built-in snapshot modes implement this interface.
/**
* This interface is used to determine details about the snapshot process:
*
* Namely:
* - Should a snapshot occur at all
* - Should streaming occur
* - What queries should be used to snapshot
*
* While many default snapshot modes are provided with Debezium,
* a custom implementation of this interface can be provided by the implementor, which
* can provide more advanced functionality, such as partial snapshots.
*
* Implementations must return true for either {@link #shouldSnapshot()} or {@link #shouldStream()}
* or true for both.
*/
@Incubating
public interface Snapshotter {
void init(PostgresConnectorConfig config, OffsetState sourceInfo,
SlotState slotState);
/**
* @return true if the snapshotter should take a snapshot
*/
boolean shouldSnapshot();
/**
* @return true if the snapshotter should stream after taking a snapshot
*/
boolean shouldStream();
/**
*
* @return true if streaming should resume from the start of the snapshot
* transaction, or false for when a connector resumes and takes a snapshot,
* streaming should resume from where streaming previously left off.
*/
default boolean shouldStreamEventsStartingFromSnapshot() {
return true;
}
/**
* @return true if when creating a slot, a snapshot should be exported, which
* can be used as an alternative to taking a lock
*/
default boolean exportSnapshot() {
return false;
}
/**
* Generate a valid postgres query string for the specified table, or an empty {@link Optional}
* to skip snapshotting this table (but that table will still be streamed from)
*
* @param tableId the table to generate a query for
* @return a valid query string, or none to skip snapshotting this table
*/
Optional<String> buildSnapshotQuery(TableId tableId);
/**
* Return a new string that set up the transaction for snapshotting
*
* @param newSlotInfo if a new slow was created for snapshotting, this contains information from
* the `create_replication_slot` command
*/
default String snapshotTransactionIsolationLevelStatement(SlotCreationResult newSlotInfo) {
// we're using the same isolation level that pg_backup uses
return "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, READ ONLY, DEFERRABLE;";
}
/**
* Returns a SQL statement for locking the given tables during snapshotting, if required by the specific snapshotter
* implementation.
*/
default Optional<String> snapshotTableLockingStatement(Duration lockTimeout, Set<TableId> tableIds) {
String lineSeparator = System.lineSeparator();
StringBuilder statements = new StringBuilder();
statements.append("SET lock_timeout = ").append(lockTimeout.toMillis()).append(";").append(lineSeparator);
// we're locking in ACCESS SHARE MODE to avoid concurrent schema changes while we're taking the snapshot
// this does not prevent writes to the table, but prevents changes to the table's schema....
// DBZ-298 Quoting name in case it has been quoted originally; it doesn't do harm if it hasn't been quoted
tableIds.forEach(tableId -> statements.append("LOCK TABLE ")
.append(tableId.toDoubleQuotedString())
.append(" IN ACCESS SHARE MODE;")
.append(lineSeparator));
return Optional.of(statements.toString());
}
}
Streaming changes
The PostgreSQL connector typically spends the vast majority of its time streaming changes from the PostgreSQL server to which it is connected. This mechanism relies on PostgreSQL’s replication protocol. This protocol enables clients to receive changes from the server as they are committed in the server’s transaction log at certain positions, which are referred to as Log Sequence Numbers (LSNs).
Whenever the server commits a transaction, a separate server process invokes a callback function from the logical decoding plug-in. This function processes the changes from the transaction, converts them to a specific format (Protobuf or JSON in the case of Debezium plug-in) and writes them on an output stream, which can then be consumed by clients.
The Debezium PostgreSQL connector acts as a PostgreSQL client. When the connector receives changes it transforms the events into Debezium create, update, or delete events that include the LSN of the event. The PostgreSQL connector forwards these change events in records to the Kafka Connect framework, which is running in the same process. The Kafka Connect process asynchronously writes the change event records in the same order in which they were generated to the appropriate Kafka topic.
Periodically, Kafka Connect records the most recent offset in another Kafka topic. The offset indicates source-specific position information that Debezium includes with each event. For the PostgreSQL connector, the LSN recorded in each change event is the offset.
When Kafka Connect gracefully shuts down, it stops the connectors, flushes all event records to Kafka, and records the last offset received from each connector. When Kafka Connect restarts, it reads the last recorded offset for each connector, and starts each connector at its last recorded offset. When the connector restarts, it sends a request to the PostgreSQL server to send the events starting just after that position.
|
The PostgreSQL connector retrieves schema information as part of the events sent by the logical decoding plug-in. However, the connector does not retrieve information about which columns compose the primary key. The connector obtains this information from the JDBC metadata (side channel). If the primary key definition of a table changes (by adding, removing or renaming primary key columns), there is a tiny period of time when the primary key information from JDBC is not synchronized with the change event that the logical decoding plug-in generates. During this tiny period, a message could be created with an inconsistent key structure. To prevent this inconsistency, update primary key structures as follows:
|
PostgreSQL 10+ logical decoding support (pgoutput
)
As of PostgreSQL 10+, there is a logical replication stream mode, called pgoutput
that is natively supported by PostgreSQL. This means that a Debezium PostgreSQL connector can consume that replication stream
without the need for additional plug-ins.
This is particularly valuable for environments where installation of plug-ins is not supported or not allowed.
See Setting up PostgreSQL for more details.
Topics names
The PostgreSQL connector writes events for all insert, update, and delete operations on a single table to a single Kafka topic. By default, the Kafka topic name is serverName.schemaName.tableName where:
-
serverName is the logical name of the connector as specified with the
database.server.name
connector configuration property. -
schemaName is the name of the database schema where the operation occurred.
-
tableName is the name of the database table in which the operation occurred.
For example, suppose that fulfillment
is the logical server name in the configuration for a connector that is capturing changes in a PostgreSQL installation that has a postgres
database and an inventory
schema that contains four tables: products
, products_on_hand
, customers
, and orders
. The connector would stream records to these four Kafka topics:
-
fulfillment.inventory.products
-
fulfillment.inventory.products_on_hand
-
fulfillment.inventory.customers
-
fulfillment.inventory.orders
Now suppose that the tables are not part of a specific schema but were created in the default public
PostgreSQL schema. The names of the Kafka topics would be:
-
fulfillment.public.products
-
fulfillment.public.products_on_hand
-
fulfillment.public.customers
-
fulfillment.public.orders
Meta information
In addition to a database change event, each record produced by a PostgreSQL connector contains some metadata. Metadata includes where the event occurred on the server, the name of the source partition and the name of the Kafka topic and partition where the event should go, for example:
"sourcePartition": {
"server": "fulfillment"
},
"sourceOffset": {
"lsn": "24023128",
"txId": "555",
"ts_ms": "1482918357011"
},
"kafkaPartition": null
-
sourcePartition
always defaults to the setting of thedatabase.server.name
connector configuration property. -
sourceOffset
contains information about the location of the server where the event occurred:-
lsn
represents the PostgreSQL Log Sequence Number oroffset
in the transaction log. -
txId
represents the identifier of the server transaction that caused the event. -
ts_ms
represents the server time at which the transaction was committed in the form of the number of microseconds since the epoch.
-
-
kafkaPartition
with a setting ofnull
means that the connector does not use a specific Kafka partition. The PostgreSQL connector uses only one Kafka Connect partition and it places the generated events into one Kafka partition.
Transaction metadata
Debezium can generate events that represent transaction boundaries and that enrich data change event messages. For every transaction BEGIN
and END
, Debezium generates an event that contains the following fields:
-
status
-BEGIN
orEND
-
id
- string representation of unique transaction identifier -
event_count
(forEND
events) - total number of events emitted by the transaction -
data_collections
(forEND
events) - an array of pairs ofdata_collection
andevent_count
that provides the number of events emitted by changes originating from given data collection
{
"status": "BEGIN",
"id": "571",
"event_count": null,
"data_collections": null
}
{
"status": "END",
"id": "571",
"event_count": 2,
"data_collections": [
{
"data_collection": "s1.a",
"event_count": 1
},
{
"data_collection": "s2.a",
"event_count": 1
}
]
}
Transaction events are written to the topic named database.server.name.transaction
.
When transaction metadata is enabled the data message Envelope
is enriched with a new transaction
field.
This field provides information about every event in the form of a composite of fields:
-
id
- string representation of unique transaction identifier -
total_order
- absolute position of the event among all events generated by the transaction -
data_collection_order
- the per-data collection position of the event among all events that were emitted by the transaction
Following is an example of a message:
{
"before": null,
"after": {
"pk": "2",
"aa": "1"
},
"source": {
...
},
"op": "c",
"ts_ms": "1580390884335",
"transaction": {
"id": "571",
"total_order": "1",
"data_collection_order": "1"
}
}
Data change events
The Debezium PostgreSQL connector generates a data change event for each row-level INSERT
, UPDATE
, and DELETE
operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed.
Debezium and Kafka Connect are designed around continuous streams of event messages. However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained.
The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A schema
field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converver and you configure it to produce all four basic change event parts, change events have this structure:
{
"schema": { (1)
...
},
"payload": { (2)
...
},
"schema": { (3)
...
},
"payload": { (4)
...
},
}
| Item | Field name | Description |
|---|---|---|
1 |
|
The first |
2 |
|
The first |
3 |
|
The second |
4 |
|
The second |
By default behavior is that the connector streams change event records to topics with names that are the same as the event’s originating table.
|
Starting with Kafka 0.10, Kafka can optionally record the event key and value with the timestamp at which the message was created (recorded by the producer) or written to the log by Kafka. |
|
The PostgreSQL connector ensures that all Kafka Connect schema names adhere to the Avro schema name format. This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or _. Each remaining character in the logical server name and each character in the schema and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character. This can lead to unexpected conflicts if the logical server name, a schema name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores. |
Change event keys
For a given table, the change event’s key has a structure that contains a field for each column in the primary key of the table at the time the event was created. Alternatively, if the table has REPLICA IDENTITY
set to FULL
or USING INDEX
there is a field for each unique key constraint.
Consider a customers
table defined in the public
database schema and the example of a change event key for that table.
CREATE TABLE customers (
id SERIAL,
first_name VARCHAR(255) NOT NULL,
last_name VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
PRIMARY KEY(id)
);
If the database.server.name
connector configuration property has the value PostgreSQL_server
, every change event for the customers
table while it has this definition has the same key structure, which in JSON looks like this:
{
"schema": { (1)
"type": "struct",
"name": "PostgreSQL_server.public.customers.Key", (2)
"optional": false, (3)
"fields": [ (4)
{
"name": "id",
"index": "0",
"schema": {
"type": "INT32",
"optional": "false"
}
}
]
},
"payload": { (5)
"id": "1"
},
}
| Item | Field name | Description |
|---|---|---|
1 |
|
The schema portion of the key specifies a Kafka Connect schema that describes what is in the key’s |
2 |
|
Name of the schema that defines the structure of the key’s payload. This schema describes the structure of the primary key for the table that was changed. Key schema names have the format connector-name.database-name.table-name.
|
3 |
|
Indicates whether the event key must contain a value in its |
4 |
|
Specifies each field that is expected in the |
5 |
|
Contains the key for the row for which this change event was generated. In this example, the key, contains a single |
|
Although the |
|
If the table does not have a primary or unique key, then the change event’s key is null. The rows in a table without a primary or unique key constraint cannot be uniquely identified. |
Change event values
The value in a change event is a bit more complicated than the key. Like the key, the value has a schema
section and a payload
section. The schema
section contains the schema that describes the Envelope
structure of the payload
section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure.
Consider the same sample table that was used to show an example of a change event key:
CREATE TABLE customers (
id SERIAL,
first_name VARCHAR(255) NOT NULL,
last_name VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
PRIMARY KEY(id)
);
The value portion of a change event for a change to this table varies according to the REPLICA IDENTITY
setting and the operation that the event is for.
Replica identity
REPLICA IDENTITY is a PostgreSQL-specific table-level setting that determines the amount of information that is available to the logical decoding plug-in for UPDATE
and DELETE
events. More specifically, the setting of REPLICA IDENTITY
controls what (if any) information is available for the previous values of the table columns involved, whenever an UPDATE
or DELETE
event occurs.
There are 4 possible values for REPLICA IDENTITY
:
-
DEFAULT
- The default behavior is thatUPDATE
andDELETE
events contain the previous values for the primary key columns of a table if that table has a primary key. For anUPDATE
event, only the primary key columns with changed values are present.If a table does not have a primary key, the connector does not emit
UPDATE
orDELETE
events for that table. For a table without a primary key, the connector emits only create events. Typically, a table without a primary key is used for appending messages to the end of the table, which means thatUPDATE
andDELETE
events are not useful. -
NOTHING
- Emitted events forUPDATE
andDELETE
operations do not contain any information about the previous value of any table column. -
FULL
- Emitted events forUPDATE
andDELETE
operations contain the previous values of all columns in the table. -
INDEX
index-name - Emitted events forUPDATE
andDELETE
operations contain the previous values of the columns contained in the specified index.UPDATE
events also contain the indexed columns with the updated values.
create events
The following example shows the value portion of a change event that the connector generates for an operation that creates data in the customers
table:
{
"schema": { (1)
"type": "struct",
"fields": [
{
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "id"
},
{
"type": "string",
"optional": false,
"field": "first_name"
},
{
"type": "string",
"optional": false,
"field": "last_name"
},
{
"type": "string",
"optional": false,
"field": "email"
}
],
"optional": true,
"name": "PostgreSQL_server.inventory.customers.Value", (2)
"field": "before"
},
{
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "id"
},
{
"type": "string",
"optional": false,
"field": "first_name"
},
{
"type": "string",
"optional": false,
"field": "last_name"
},
{
"type": "string",
"optional": false,
"field": "email"
}
],
"optional": true,
"name": "PostgreSQL_server.inventory.customers.Value",
"field": "after"
},
{
"type": "struct",
"fields": [
{
"type": "string",
"optional": false,
"field": "version"
},
{
"type": "string",
"optional": false,
"field": "connector"
},
{
"type": "string",
"optional": false,
"field": "name"
},
{
"type": "int64",
"optional": false,
"field": "ts_sec"
},
{
"type": "boolean",
"optional": true,
"default": false,
"field": "snapshot"
},
{
"type": "string",
"optional": false,
"field": "db"
},
{
"type": "string",
"optional": false,
"field": "schema"
},
{
"type": "string",
"optional": false,
"field": "table"
},
{
"type": "int64",
"optional": true,
"field": "txId"
},
{
"type": "int64",
"optional": true,
"field": "lsn"
},
{
"type": "int64",
"optional": true,
"field": "xmin"
}
],
"optional": false,
"name": "io.debezium.connector.postgresql.Source", (3)
"field": "source"
},
{
"type": "string",
"optional": false,
"field": "op"
},
{
"type": "int64",
"optional": true,
"field": "ts_ms"
}
],
"optional": false,
"name": "PostgreSQL_server.inventory.customers.Envelope" (4)
},
"payload": { (5)
"before": null, (6)
"after": { (7)
"id": 1,
"first_name": "Anne",
"last_name": "Kretchmar",
"email"<EMAIL_ADDRESS>},
"source": { (8)
"version": "1.3.1.Final",
"connector": "postgresql",
"name": "PostgreSQL_server",
"ts_sec":<PHONE_NUMBER>863,
"snapshot": true,
"db": "postgres",
"schema": "public",
"table": "customers",
"txId": 555,
"lsn": 24023128,
"xmin": null
},
"op": "c", (9)
"ts_ms":<PHONE_NUMBER>863 (10)
}
}
| Item | Field name | Description | ||
|---|---|---|---|---|
1 |
|
The value’s schema, which describes the structure of the value’s payload. A change event’s value schema is the same in every change event that the connector generates for a particular table. |
||
2 |
|
In the |
||
3 |
|
|
||
4 |
|
|
||
5 |
|
The value’s actual data. This is the information that the change event is providing. |
||
6 |
|
An optional field that specifies the state of the row before the event occurred. When the
|
||
7 |
|
An optional field that specifies the state of the row after the event occurred. In this example, the |
||
8 |
|
Mandatory field that describes the source metadata for the event. This field contains information that you can use to compare this event with other events, with regard to the origin of the events, the order in which the events occurred, and whether events were part of the same transaction. The source metadata includes:
|
||
9 |
|
Mandatory string that describes the type of operation that caused the connector to generate the event. In this example,
|
||
10 |
|
Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. |
update events
The value of a change event for an update in the sample customers
table has the same schema as a create event for that table. Likewise, the event value’s payload has the same structure. However, the event value payload contains different values in an update event. Here is an example of a change event value in an event that the connector generates for an update in the customers
table:
{
"schema": { ... },
"payload": {
"before": { (1)
"id": 1
},
"after": { (2)
"id": 1,
"first_name": "Anne Marie",
"last_name": "Kretchmar",
"email"<EMAIL_ADDRESS>},
"source": { (3)
"version": "1.3.1.Final",
"connector": "postgresql",
"name": "PostgreSQL_server",
"ts_sec":<PHONE_NUMBER>863,
"snapshot": null,
"db": "postgres",
"schema": "public",
"table": "customers",
"txId": 556,
"lsn": 24023128,
"xmin": null
},
"op": "u", (4)
"ts_ms":<PHONE_NUMBER>523
}
}
| Item | Field name | Description |
|---|---|---|
1 |
|
An optional field that contains values that were in the row before the database commit. In this example, only the primary key column, |
2 |
|
An optional field that specifies the state of the row after the event occurred. In this example, the |
3 |
|
Mandatory field that describes the source metadata for the event. The
|
4 |
|
Mandatory string that describes the type of operation. In an update event value, the |
|
Updating the columns for a row’s primary/unique key changes the value of the row’s key. When a key changes, Debezium outputs three events: a |
Primary key updates
An UPDATE
operation that changes a row’s primary key field(s) is known
as a primary key change. For a primary key change, in place of sending an UPDATE
event record, the connector sends a DELETE
event record for the old key and a CREATE
event record for the new (updated) key. These events have the usual structure and content, and in addition, each one has a message header related to the primary key change:
-
The
DELETE
event record has__debezium.newkey
as a message header. The value of this header is the new primary key for the updated row. -
The
CREATE
event record has__debezium.oldkey
as a message header. The value of this header is the previous (old) primary key that the updated row had.
delete events
The value in a delete change event has the same schema
portion as create and update events for the same table. The payload
portion in a delete event for the sample customers
table looks like this:
{
"schema": { ... },
"payload": {
"before": { (1)
"id": 1
},
"after": null, (2)
"source": { (3)
"version": "1.3.1.Final",
"connector": "postgresql",
"name": "PostgreSQL_server",
"ts_ms":<PHONE_NUMBER>863,
"snapshot": null,
"db": "postgres",
"schema": "public",
"table": "customers",
"txId": 556,
"lsn": 46523128,
"xmin": null
},
"op": "d", (4)
"ts_ms":<PHONE_NUMBER>461 (5)
}
}
| Item | Field name | Description |
|---|---|---|
1 |
|
Optional field that specifies the state of the row before the event occurred. In a delete event value, the |
2 |
|
Optional field that specifies the state of the row after the event occurred. In a delete event value, the |
3 |
|
Mandatory field that describes the source metadata for the event. In a delete event value, the
|
4 |
|
Mandatory string that describes the type of operation. The |
5 |
|
Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. |
A delete change event record provides a consumer with the information it needs to process the removal of this row.
|
For a consumer to be able to process a delete event generated for a table that does not have a primary key, set the table’s |
PostgreSQL connector events are designed to work with Kafka log compaction. Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state.
When a row is deleted, the delete event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be null
. To make this possible, the PostgreSQL connector follows a delete event with a special tombstone event that has the same key but a null
value.
Data type mappings
The PostgreSQL connector represents changes to rows with events that are structured like the table in which the row exists. The event contains a field for each column value. How that value is represented in the event depends on the PostgreSQL data type of the column. This section describes these mappings.
Basic types
The following table describes how the connector maps basic PostgreSQL data types to a literal type and a semantic type in event fields.
-
literal type describes how the value is literally represented using Kafka Connect schema types:
INT8
,INT16
,INT32
,INT64
,FLOAT32
,FLOAT64
,BOOLEAN
,STRING
,BYTES
,ARRAY
,MAP
, andSTRUCT
. -
semantic type describes how the Kafka Connect schema captures the meaning of the field using the name of the Kafka Connect schema for the field.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
n/a |
|
|
n/a |
|
|
|
|
|
|
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
n/a |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
|
Temporal types
Other than PostgreSQL’s TIMESTAMPTZ
and TIMETZ
data types, which contain time zone information, how temporal types are mapped depends on the value of the time.precision.mode
connector configuration property. The following sections describe these mappings:
time.precision.mode=adaptive
When the time.precision.mode
property is set to adaptive
, the default, the connector determines the literal type and semantic type based on the column’s data type definition. This ensures that events exactly represent the values in the database.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
time.precision.mode=adaptive_time_microseconds
When the time.precision.mode
configuration property is set to adaptive_time_microseconds
, the connector determines the literal type and semantic type for temporal types based on the column’s data type definition. This ensures that events exactly represent the values in the database, except all TIME
fields are captured as microseconds.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
time.precision.mode=connect
When the time.precision.mode
configuration property is set to connect
, the connector uses Kafka Connect logical types. This may be useful when consumers can handle only the built-in Kafka Connect logical types and are unable to handle variable-precision time values. However, since PostgreSQL supports microsecond precision, the events generated by a connector with the connect
time precision mode results in a loss of precision when the database column has a fractional second precision value that is greater than 3.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
|
|
|
|
|
|
|
TIMESTAMP type
The TIMESTAMP
type represents a timestamp without time zone information.
Such columns are converted into an equivalent Kafka Connect value based on UTC. For example, the TIMESTAMP
value "2018-06-20 15:13:16.945104" is represented by an io.debezium.time.MicroTimestamp
with the value "1529507596945104" when time.precision.mode
is not set to connect
.
The timezone of the JVM running Kafka Connect and Debezium does not affect this conversion.
Decimal types
The setting of the PostgreSQL connector configuration property, decimal.handling.mode
determines how the connector maps decimal types.
When the decimal.handling.mode
property is set to precise
, the connector uses the Kafka Connect org.apache.kafka.connect.data.Decimal
logical type for all DECIMAL
and NUMERIC
columns. This is the default mode.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
|
|
|
|
There is an exception to this rule.
When the NUMERIC
or DECIMAL
types are used without scale constraints, the values coming from the database have a different (variable) scale for each value. In this case, the connector uses io.debezium.data.VariableScaleDecimal
, which contains both the value and the scale of the transferred value.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
|
|
|
|
When the decimal.handling.mode
property is set to double
, the connector represents all DECIMAL
and NUMERIC
values as Java double values and encodes them as shown in the following table.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) |
|---|---|---|
|
|
|
|
|
The last possible setting for the decimal.handling.mode
configuration property is string
. In this case, the connector represents DECIMAL
and NUMERIC
values as their formatted string representation, and encodes them as shown in the following table.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) |
|---|---|---|
|
|
|
|
|
PostgreSQL supports NaN
(not a number) as a special value to be stored in DECIMAL
/NUMERIC
values when the setting of decimal.handling.mode
is string
or double
. In this case, the connector encodes NaN
as either Double.NaN
or the string constant NAN
.
HSTORE type
When the hstore.handling.mode
connector configuration property is set to json
(the default), the connector represents HSTORE
values as string representations of JSON values and encodes them as shown in the following table. When the hstore.handling.mode
property is set to map
, the connector uses the MAP
schema type for HSTORE
values.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
|
|
|
n/a |
Domain types
PostgreSQL supports user-defined types that are based on other underlying types. When such column types are used, Debezium exposes the column’s representation based on the full type hierarchy.
|
Capturing changes in columns that use PostgreSQL domain types requires special consideration. When a column is defined to contain a domain type that extends one of the default database types and the domain type defines a custom length or scale, the generated schema inherits that defined length or scale. When a column is defined to contain a domain type that extends another domain type that defines a custom length or scale, the generated schema does not inherit the defined length or scale because that information is not available in the PostgreSQL driver’s column metadata. |
Network address types
PostgreSQL has data types that can store IPv4, IPv6, and MAC addresses. It is better to use these types instead of plain text types to store network addresses. Network address types offer input error checking and specialized operators and functions.
| PostgreSQL data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
n/a |
|
|
n/a |
|
|
n/a |
|
|
n/a |
PostGIS types
The PostgreSQL connector supports all PostGIS data types.
| PostGIS data type | Literal type (schema type) | Semantic type (schema name) and Notes |
|---|---|---|
|
|
For format details, see Open Geospatial Consortium Simple Features Access specification. |
|
|
For format details, see Open Geospatial Consortium Simple Features Access specification. |
Toasted values
PostgreSQL has a hard limit on the page size. This means that values that are larger than around 8 KBs need to be stored by using link::https://www.postgresql.org/docs/current/storage-toast.html[TOAST storage]. This impacts replication messages that are coming from the database. Values that were stored by using the TOAST mechanism and that have not been changed are not included in the message, unless they are part of the table’s replica identity. There is no safe way for Debezium to read the missing value out-of-bands directly from the database, as this would potentially lead to race conditions. Consequently, Debezium follows these rules to handle toasted values:
-
Tables with
REPLICA IDENTITY FULL
- TOAST column values are part of thebefore
andafter
fields in change events just like any other column. -
Tables with
REPLICA IDENTITY DEFAULT
- When receiving anUPDATE
event from the database, any unchanged TOAST column value that is not part of the replica identity is not contained in the event. Similarly, when receiving aDELETE
event, no TOAST columns, if any, are in thebefore
field. As Debezium cannot safely provide the column value in this case, the connector returns a placeholder value as defined by the connector configuration property,toasted.value.placeholder
.
|
There is a problem related to Amazon RDS instances. The
|
Set up
Before using the PostgreSQL connector to monitor the changes committed on a PostgreSQL server, decide which logical decoding plug-in you intend to use.
If you plan not to use the native pgoutput
logical replication stream support, then you must install the logical decoding plug-in into the PostgreSQL server. Afterward, enable a replication slot, and configure a user with sufficient privileges to perform the replication.
If your database is hosted by a service such as Heroku Postgres you might be unable to install the plug-in. If so, and if you are using PostgreSQL 10+, you can use the pgoutput
decoder support to capture changes in your database. If that is not an option, you are unable to use Debezium with your database.
PostgreSQL in the Cloud
PostgreSQL on Amazon RDS
It is possible to capture changes in a PostgreSQL database that is running in Amazon RDS. To do this:
-
Set the instance parameter
rds.logical_replication
to1
. -
Verify that the
wal_level
parameter is set tological
by running the querySHOW wal_level
as the database RDS master user. This might not be the case in multi-zone replication setups. You cannot set this option manually. It is automatically changed when therds.logical_replication
parameter is set to1
. If thewal_level
is notlogical
after the change above, it is probably because the instance has to be restarted due to the parameter group change. This happens according to your maintenance window or you can do it manually. -
Set the Debezium
plugin.name
parameter towal2json
. You can skip this on PostgreSQL 10+ if you plan to usepgoutput
logical replication stream support. -
Use the RDS master account for replication as RDS currently does not support setting of
REPLICATION
privilege for another account.
|
Ensure that you use the latest versions of PostgreSQL 9.6, 10 or 11 on Amazon RDS.
Otherwise, older versions of the As of January 2019, the following PostgreSQL versions on RDS come with an up-to-date version of
|
PostgreSQL on Azure
It is possible to use Debezium with Azure Database for PostgreSQL, which has support for the wal2json
and pgoutput
plug-ins, both of which are supported by Debezium as well.
Set the Azure replication support to logical
. You can use the Azure CLI or the Azure Portal to configure this. For example, to use the Azure CLI, here are the az postgres server
commands that you need to execute:
az postgres server configuration set --resource-group mygroup --server-name myserver --name azure.replication_support --value logical
az postgres server restart --resource-group mygroup --name myserver
|
While using the |
Installing the logical decoding output plug-in
|
See Logical Decoding Output Plug-in Installation for PostgreSQL for more detailed instructions for setting up and testing logical decoding plug-ins. |
|
As of Debezium 0.10, the connector supports PostgreSQL 10+ logical replication streaming by using |
As of PostgreSQL 9.4, the only way to read changes to the write-ahead-log is to install a logical decoding output plug-in. Plug-ins are written in C, compiled, and installed on the machine that runs the PostgreSQL server. Plug-ins use a number of PostgreSQL specific APIs, as described by the PostgreSQL documentation.
The PostgreSQL connector works with one of Debezium’s supported logical decoding plug-ins to encode the changes in either Protobuf format or JSON format. See the documentation for your chosen plug-in to learn more about the plug-in’s requirements, limitations, and how to compile it.
For simplicity, Debezium also provides a Docker image based on a vanilla PostgreSQL server image on top of which it compiles and installs the plug-ins. You can use this image as an example of the detailed steps required for the installation.
|
The Debezium logical decoding plug-ins have been installed and tested on only Linux machines. For Windows and other operating systems, different installation steps might be required. |
Plug-in differences
Plug-in behavior is not completely the same for all cases. These differences have been identified:
-
The
wal2json
anddecoderbufs
plug-ins emit events for tables without primary keys. -
The
wal2json
plug-in does not support special values, such asNaN
orinfinity
, for floating point types. -
The
wal2json
plug-in should be used with theschema.refresh.mode
connector configuration property set tocolumns_diff_exclude_unchanged_toast
. Otherwise, when receiving a change event for a row that contains an unchangedTOAST
column, no field for that column is contained in the emitted change event’safter
field. This is becausewal2json
plug-in messages do not contain a field for such a column.The requirement for adding this is tracked under the
wal2json
issue 98. See the documentation ofcolumns_diff_exclude_unchanged_toast
further below for implications of using it. -
The
pgoutput
plug-in does not emit all events for tables without primary keys. It emits only events forINSERT
operations.
All up-to-date differences are tracked in a test suite Java class.
Configuring the PostgreSQL server
If you are using one of the supported logical decoding plug-ins, that is, not pgoutput
, and it has been installed, configure the PostgreSQL server as follows:
-
To load the plug-in at startup, add the following to the
postgresql.conf
file::# MODULES shared_preload_libraries = 'decoderbufs,wal2json' (1)
-
To configure the replication slot regardless of the decoder being used, specify the following in the
postgresql.conf
file:# REPLICATION wal_level = logical (1) max_wal_senders = 1 (2) max_replication_slots = 1 (3)
1 instructs the server to use logical decoding with the write-ahead log. 2 instructs the server to use a maximum of 1
separate process for processing WAL changes.3 instructs the server to allow a maximum of 1
replication slot to be created for streaming WAL changes.
Debezium uses PostgreSQL’s logical decoding, which uses replication slots. Replication slots are guaranteed to retain all WAL segments required for Debezium even during Debezium outages. For this reason, it is important to closely monitor replication slots to avoid too much disk consumption and other conditions that can happen such as catalog bloat if a replication slot stays unused for too long. For more information, see the PostgreSQL streaming replication documentation.
If you are working with a synchronous_commit
setting other than on
,
the recommendation is to set wal_writer_delay
to a value such as 10 milliseconds to achieve a low latency of change events.
Otherwise, its default value is applied, which adds a latency of about 200 milliseconds.
|
Reading and understanding PostgreSQL documentation about the mechanics and configuration of the PostgreSQL write-ahead log is strongly recommended. |
Setting up permissions
Setting up a PostgreSQL server to run a Debezium connector requires a database user who can perform replications. Replication can be performed only by a database user who has appropriate permissions and only for a configured number of hosts. Also, you must configure the PostgreSQL server to allow replication to take place between the server machine and the host on which the PostgreSQL connector is running.
-
PostgreSQL administrative permissions.
-
To give replication permissions to a user, define a PostgreSQL role that has at least the
REPLICATION
andLOGIN
permissions. For example:CREATE ROLE name REPLICATION LOGIN;
By default, superusers have both of the above roles.
-
Configure the PostgreSQL server to allow replication to take place between the server machine and the host on which the PostgreSQL connector is running.
pg_hba.conf
file example:local replication <youruser> trust (1) host replication <youruser> <IP_ADDRESS>/32 trust (2) host replication <youruser> ::1/128 trust (3)
1 Instructs the server to allow replication for <youruser>
locally, that is, on the server machine.2 Instructs the server to allow <youruser>
onlocalhost
to receive replication changes usingIPV4
.3 Instructs the server to allow <youruser>
onlocalhost
to receive replication changes usingIPV6
.
|
For more information about network masks, see the PostgreSQL documentation. |
Supported PostgreSQL topologies
The PostgreSQL connector can be used with a standalone PostgreSQL server or with a cluster of PostgreSQL servers.
As mentioned in the beginning, PostgreSQL (for all versions ⇐ 12) supports logical replication slots on only primary
servers. This means that a replica in a PostgreSQL cluster cannot be configured for logical replication, and consequently that the Debezium PostgreSQL connector can connect and communicate with only the primary server. Should this server fail, the connector stops. When the cluster is repaired, if the original primary server is once again promoted to primary
, you can retart the connector. However, if a different PostgreSQL server with the plug-in and proper configuration is promoted to primary
, you must change the connector configuration to point to the new primary
server and then you can restart the connector.
WAL disk space consumption
In certain cases, it is possible for PostgreSQL disk space consumed by WAL files to spike or increase out of usual proportions. There are several possible reasons for this situation:
-
The LSN up to which the connector has received data is available in the
confirmed_flush_lsn
column of the server’spg_replication_slots
view. Data that is older than this LSN is no longer available, and the database is responsible for reclaiming the disk space.Also in the
pg_replication_slots
view, therestart_lsn
column contains the LSN of the oldest WAL that the connector might require. If the value forconfirmed_flush_lsn
is regularly increasing and the value ofrestart_lsn
lags then the database needs to reclaim the space.The database typically reclaims disk space in batch blocks. This is expected behavior and no action by a user is necessary.
-
There are many updates in a database that is being tracked but only a tiny number of updates are related to the table(s) and schema(s) for which the connector is capturing changes. This situation can be easily solved with periodic heartbeat events. Set the
heartbeat.interval.ms
connector configuration property. -
The PostgreSQL instance contains multiple databases and one of them is a high-traffic database. Debezium captures changes in another database that is low-traffic in comparison to the other database. Debezium then cannot confirm the LSN as replication slots work per-database and Debezium is not invoked. As WAL is shared by all databases, the amount used tends to grow until an event is emitted by the database for which Debezium is capturing changes. To overcome this, it is necessary to:
-
Enable periodic heartbeat record generation with the
heartbeat.interval.ms
connector configuration property. -
Regularly emit change events from the database for which Debezium is capturing changes.
In the case of
wal2json
decoder plug-in, it is sufficient to generate empty events. This can be achieved for example by truncating an empty temporary table. For other decoder plug-ins, the recommendation is to create a supplementary table for which Debezium is not capturing changes.
A separate process would then periodically update the table by either inserting a new row or repeatedly updating the same row. PostgreSQL then invokes Debezium, which confirms the latest LSN and allows the database to reclaim the WAL space. This task can be automated by means of the
heartbeat.action.query
connector configuration property. -
|
For users on AWS RDS with PostgreSQL, a situation similar to the high traffic/low traffic scenario can occur in an idle environment. AWS RDS causes writes to its own system tables to be invisible to clients on a frequent basis (5 minutes). Again, regularly emitting events solves the problem. |
Deployment
With Zookeeper, Kafka, and Kafka Connect installed, the remaining tasks to deploy a Debezium PostgreSQL connector are to download the connector’s plug-in archive, extract the JAR files into your Kafka Connect environment, and add the directory with the JAR files to Kafka Connect’s plugin.path
. You then need to restart your Kafka Connect process to pick up the new JAR files.
If you are working with immutable containers, see Debezium’s Container images for Zookeeper, Kafka, PostgreSQL and Kafka Connect with the PostgreSQL connector already installed and ready to run. You can also run Debezium on Kubernetes and OpenShift.
Connector configuration example
Following is an example of the configuration for a PostgreSQL connector that connects to a PostgreSQL server on port 5432 at <IP_ADDRESS>, whose logical name is fullfillment
. Typically, you configure the Debezium PostgreSQL connector in a .json
file using the configuration properties available for the connector.
You can choose to produce events for a subset of the schemas and tables. Optionally, ignore, mask, or truncate columns that are sensitive, too large, or not needed.
{
"name": "inventory-connector", (1)
"config": {
"connector.class": "io.debezium.connector.postgresql.PostgresConnector", (2)
"database.hostname": "<IP_ADDRESS>", (3)
"database.port": "5432", (4)
"database.user": "postgres", (5)
"database.password": "postgres", (6)
"database.dbname" : "postgres", (7)
"database.server.name": "fullfillment", (8)
"table.include.list": "public.inventory" (9)
}
}
| 1 | The name of the connector when registered with a Kafka Connect service. |
| 2 | The name of this PostgreSQL connector class. |
| 3 | The address of the PostgreSQL server. |
| 4 | The port number of the PostgreSQL server. |
| 5 | The name of the PostgreSQL user that has the required privileges. |
| 6 | The password for the PostgreSQL user that has the required privileges. |
| 7 | The name of the PostgreSQL database to connect to |
| 8 | The logical name of the PostgreSQL server/cluster, which forms a namespace and is used in all the names of the Kafka topics to which the connector writes, the Kafka Connect schema names, and the namespaces of the corresponding Avro schema when the Avro converter is used. |
| 9 | A list of all tables hosted by this server that this connector will monitor. This is optional, and there are other properties for listing the schemas and tables to include or exclude from monitoring. |
See the complete list of PostgreSQL connector properties that can be specified in these configurations.
You can send this configuration with a POST
command to a running Kafka Connect service. The service records the configuration and starts the connector task that connects to the PostgreSQL database and streams change event records to Kafka topics.
Adding connector configuration
To start running a PostgreSQL connector, create a connector configuration and add the configuration to your Kafka Connect cluster.
-
The PostgreSQL server is configured to support logical replication.
-
The logical decoding plug-in is installed.
-
The PostgreSQL connector is installed.
-
Create a configuration for the PostgreSQL connector.
-
Use the Kafka Connect REST API to add that connector configuration to your Kafka Connect cluster.
When the connector starts, it performs a consistent snapshot of the PostgreSQL server databases that the connector is configured for. The connector then starts generating data change events for row-level operations and streaming change event records to Kafka topics.
Monitoring
The Debezium PostgreSQL connector provides two types of metrics that are in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect provide.
-
Snapshot metrics provide information about connector operation while performing a snapshot.
-
Streaming metrics provide information about connector operation when the connector is capturing changes and streaming change event records.
Debezium monitoring documentation provides details for how to expose these metrics by using JMX.
Snapshot metrics
The MBean is debezium.postgres:type=connector-metrics,context=snapshot,server=<database.server.name>
.
| Attributes | Type | Description |
|---|---|---|
|
The last snapshot event that the connector has read. |
|
|
The number of milliseconds since the connector has read and processed the most recent event. |
|
|
The total number of events that this connector has seen since last started or reset. |
|
|
The number of events that have been filtered by include/exclude list filtering rules configured on the connector. |
|
|
The list of tables that are monitored by the connector. |
|
|
The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. |
|
|
The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. |
|
|
The total number of tables that are being included in the snapshot. |
|
|
The number of tables that the snapshot has yet to copy. |
|
|
Whether the snapshot was started. |
|
|
Whether the snapshot was aborted. |
|
|
Whether the snapshot completed. |
|
|
The total number of seconds that the snapshot has taken so far, even if not complete. |
|
|
Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. |
Streaming metrics
The MBean is debezium.postgres:type=connector-metrics,context=streaming,server=<database.server.name>
.
| Attributes | Type | Description |
|---|---|---|
|
The last streaming event that the connector has read. |
|
|
The number of milliseconds since the connector has read and processed the most recent event. |
|
|
The total number of events that this connector has seen since last started or reset. |
|
|
The number of events that have been filtered by include/exclude list filtering rules configured on the connector. |
|
|
The list of tables that are monitored by the connector. |
|
|
The length the queue used to pass events between the streamer and the main Kafka Connect loop. |
|
|
The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. |
|
|
Flag that denotes whether the connector is currently connected to the database server. |
|
|
The number of milliseconds between the last change event’s timestamp and the connector processing it. The values will incoporate any differences between the clocks on the machines where the database server and the connector are running. |
|
|
The number of processed transactions that were committed. |
|
|
The coordinates of the last received event. |
|
|
Transaction identifier of the last processed transaction. |
Connector configuration properties
The Debezium PostgreSQL connector has many configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows:
The following configuration properties are required unless a default value is available.
| Property | Default | Description |
|---|---|---|
Unique name for the connector. Attempting to register again with the same name will fail. This property is required by all Kafka Connect connectors. |
||
The name of the Java class for the connector. Always use a value of |
||
|
The maximum number of tasks that should be created for this connector. The PostgreSQL connector always uses a single task and therefore does not use this value, so the default is always acceptable. |
|
|
The name of the PostgreSQL logical decoding plug-in installed on the PostgreSQL server. Supported values are If you are using a |
|
|
The name of the PostgreSQL logical decoding slot that was created for streaming changes from a particular plug-in for a particular database/schema. The server uses this slot to stream events to the Debezium connector that you are configuring. Slot names must conform to PostgreSQL replication slot naming rules, which state: "Each replication slot has a name, which can contain lower-case letters, numbers, and the underscore character." |
|
|
Whether or not to delete the logical replication slot when the connector stops in a graceful, expected way. The default behavior is that the replication slot remains configured for the connector when the connector stops. When the connector restarts, having the same replication slot enables the connector to start processing where it left off. Set to |
|
|
The name of the PostgreSQL publication created for streaming changes when using This publication is created at start-up if it does not already exist and it includes all tables. Debezium then applies its own include/exclude list filtering, if configured, to limit the publication to change events for the specific tables of interest. The connector user must have superuser permissions to create this publication, so it is usually preferable to create the publication before starting the connector for the first time. If the publication already exists, either for all tables or configured with a subset of tables, Debezium uses the publication as it is defined. |
|
IP address or hostname of the PostgreSQL database server. |
||
|
Integer port number of the PostgreSQL database server. |
|
Name of the PostgreSQL database user for connecting to the PostgreSQL database server. |
||
Password to use when connecting to the PostgreSQL database server. |
||
The name of the PostgreSQL database from which to stream the changes. |
||
Logical name that identifies and provides a namespace for the particular PostgreSQL database server or cluster in which Debezium is capturing changes. Only alphanumeric characters and underscores should be used in the database server logical name. The logical name should be unique across all other connectors, since it is used as a topic name prefix for all Kafka topics that receive records from this connector. |
||
An optional, comma-separated list of regular expressions that match names of schemas for which you want to capture changes. Any schema name not included in |
||
An optional, comma-separated list of regular expressions that match names of schemas for which you do not want to capture changes. Any schema whose name is not included in |
||
An optional, comma-separated list of regular expressions that match fully-qualified table identifiers for tables whose changes you want to capture. Any table not included in |
||
An optional, comma-separated list of regular expressions that match fully-qualified table identifiers for tables whose changes you do not want to capture. Any table not included in |
||
An optional, comma-separated list of regular expressions that match the fully-qualified names of columns that should be included in change event record values. Fully-qualified names for columns are of the form schemaName.tableName.columnName. Do not also set the |
||
An optional, comma-separated list of regular expressions that match the fully-qualified names of columns that should be excluded from change event record values. Fully-qualified names for columns are of the form schemaName.tableName.columnName. Do not also set the |
||
|
Time, date, and timestamps can be represented with different kinds of precision: |
|
|
Specifies how the connector should handle values for |
|
|
Specifies how the connector should handle values for |
|
|
Specifies how the connector should handle values for |
|
|
Whether to use an encrypted connection to the PostgreSQL server. Options include: |
|
The path to the file that contains the SSL certificate for the client. See the PostgreSQL documentation for more information. |
||
The path to the file that contains the SSL private key of the client. See the PostgreSQL documentation for more information. |
||
The password to access the client private key from the file specified by |
||
The path to the file that contains the root certificate(s) against which the server is validated. See the PostgreSQL documentation for more information. |
||
|
Enable TCP keep-alive probe to verify that the database connection is still alive. See the PostgreSQL documentation for more information. |
|
|
Controls whether a tombstone event should be generated after a delete event. |
|
n/a |
An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form schemaName.tableName.columnName. In change event records, values in these columns are truncated if they are longer than the number of characters specified by length in the property name. You can specify multiple properties with different lengths in a single configuration. Length must be a positive integer, for example, |
|
n/a |
An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form schemaName.tableName.columnName. In change event values, the values in the specified table columns are replaced with length number of asterisk ( |
|
n/a |
An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form schemaName.tableName.columnName. In change event values, the values in the specified columns are replaced with pseudonyms. |
|
n/a |
An optional, comma-separated list of regular expressions that match the fully-qualified names of columns. Fully-qualified names for columns are of the form databaseName.tableName.columnName, or databaseName.schemaName.tableName.columnName. |
|
n/a |
An optional, comma-separated list of regular expressions that match the database-specific data type name for some columns. Fully-qualified data type names are of the form databaseName.tableName.typeName, or databaseName.schemaName.tableName.typeName. |
|
empty string |
A semicolon separated list of tables with regular expressions that match table column names. The connector maps values in matching columns to key fields in change event records that it sends to Kafka topics. This is useful when a table does not have a primary key, or when you want to order change event records in a Kafka topic according to a field that is not a primary key. |
|
all_tables |
Applies only when streaming changes by using the |
|
bytes |
Specifies how binary ( |
The following advanced configuration properties have defaults that work in most situations and therefore rarely need to be specified in the connector’s configuration.
| Property | Default | Description | ||
|---|---|---|---|---|
|
Specifies the criteria for performing a snapshot when the connector starts: |
|||
A full Java class name that is an implementation of the |
||||
|
Positive integer value that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If the connector cannot acquire table locks in this time interval, the snapshot fails. How the connector performs snapshots provides details. |
|||
Controls which table rows are included in snapshots. This property affects snapshots only. It does not affect events that are generated by the logical decoding plug-in. Specify a comma-separated list of fully-qualified table names in the form databaseName.tableName. |
||||
|
Specifies how the connector should react to exceptions during processing of events: |
|||
|
Positive integer value for the maximum size of the blocking queue. The connector places change events received from streaming replication in the blocking queue before writing them to Kafka. This queue can provide backpressure when, for example, writing records to Kafka is slower that it should be or Kafka is not available. |
|||
|
Positive integer value that specifies the maximum size of each batch of events that the connector processes. |
|||
|
Positive integer value that specifies the number of milliseconds the connector should wait for new change events to appear before it starts processing a batch of events. Defaults to 1000 milliseconds, or 1 second. |
|||
|
Specifies connector behavior when the connector encounters a field whose data type is unknown. The default behavior is that the connector omits the field from the change event and logs a warning.
|
|||
A semicolon separated list of SQL statements that the connector executes when it establishes a JDBC connection to the database. To use a semicolon as a character and not as a delimiter, specify two consecutive semicolons, |
||||
|
Controls how frequently the connector sends heartbeat messages to a Kafka topic. The default behavior is that the connector does not send heartbeat messages. |
|||
|
Controls the name of the topic to which the connector sends heartbeat messages. The topic name has this pattern: |
|||
Specifies a query that the connector executes on the source database when the connector sends a heartbeat message. |
||||
|
Specify the conditions that trigger a refresh of the in-memory schema for a table. |
|||
An interval in milliseconds that the connector should wait before performing a snapshot when the connector starts. If you are starting multiple connectors in a cluster, this property is useful for avoiding snapshot interruptions, which might cause re-balancing of connectors. |
||||
|
During a snapshot, the connector reads table content in batches of rows. This property specifies the maximum number of rows in a batch. |
|||
Semicolon separated list of parameters to pass to the configured logical decoding plug-in. For example, If you are using the |
||||
|
Indicates whether field names are sanitized to adhere to Avro naming requirements. |
|||
|
If connecting to a replication slot fails, this is the maximum number of consecutive attempts to connect. |
|||
|
The number of milliseconds to wait between retry attempts when the connector fails to connect to a replication slot. |
|||
|
Specifies the constant that the connector provides to indicate that the original value is a toasted value that is not provided by the database.
If the setting of |
|||
|
Determines whether the connector generates events with transaction boundaries and enriches change event envelopes with transaction metadata. Specify |
|||
10000 (10 seconds) |
The number of milliseconds to wait before restarting a connector after a retriable error occurs. |
The connector also supports pass-through configuration properties that are used when creating the Kafka producer and consumer.
Be sure to consult the Kafka documentation for all of the configuration properties for Kafka producers and consumers. The PostgreSQL connector does use the new consumer configuration properties.
Behavior when things go wrong
Debezium is a distributed system that captures all changes in multiple upstream databases; it never misses or loses an event. When the system is operating normally or being managed carefully then Debezium provides exactly once delivery of every change event record.
If a fault does happen then the system does not lose any events. However, while it is recovering from the fault, it might repeat some change events. In these abnormal situations, Debezium, like Kafka, provides at least once delivery of change events.
The rest of this section describes how Debezium handles various kinds of faults and problems.
Configuration and startup errors
In the following situations, the connector fails when trying to start, reports an error/exception in the log, and stops running:
-
The connector’s configuration is invalid.
-
The connector cannot successfully connect to PostgreSQL by using the specified connection parameters.
-
The connector is restarting from a previously-recorded position in the PostgreSQL WAL (by using the LSN) and PostgreSQL no longer has that history available.
In these cases, the error message has details about the problem and possibly a suggested workaround. After you correct the configuration or address the PostgreSQL problem, restart the connector.
PostgreSQL becomes unavailable
When the connector is running, the PostgreSQL server that it is connected to could become unavailable for any number of reasons. If this happens, the connector fails with an error and stops. When the server is available again, restart the connector.
The PostgreSQL connector externally stores the last processed offset in the form of a PostgreSQL LSN. After a connector restarts and connects to a server instance, the connector communicates with the server to continue streaming from that particular offset. This offset is available as long as the Debezium replication slot remains intact. Never drop a replication slot on the primary server or you will lose data. See the next section for failure cases in which a slot has been removed.
Cluster failures
As of release 12, PostgreSQL allows logical replication slots only on primary servers. This means that you can point a Debezium PostgreSQL connector to only the active primary server of a database cluster. Also, replication slots themselves are not propagated to replicas. If the primary server goes down, a new primary must be promoted.
The new primary must have the logical decoding plug-in installed and a replication slot that is configured for use by the plug-in and the database for which you want to capture changes. Only then can you point the connector to the new server and restart the connector.
There are important caveats when failovers occur and you should pause Debezium until you can verify that you have an intact replication slot that has not lost data. After a failover:
-
There must be a process that re-creates the Debezium replication slot before allowing the application to write to the new primary. This is crucial. Without this process, your application can miss change events.
-
You might need to verify that Debezium was able to read all changes in the slot before the old primary failed.
One reliable method of recovering and verifying whether any changes were lost is to recover a backup of the failed primary to the point immediately before it failed. While this can be administratively difficult, it allows you to inspect the replication slot for any unconsumed changes.
|
There are discussions in the PostgreSQL community around a feature called More about the concept of failover slots is in this blog post. |
Kafka Connect process stops gracefully
Suppose that Kafka Connect is being run in distributed mode and a Kafka Connect process is stopped gracefully. Prior to shutting down that process, Kafka Connect migrates the process’s connector tasks to another Kafka Connect process in that group. The new connector tasks start processing exactly where the prior tasks stopped. There is a short delay in processing while the connector tasks are stopped gracefully and restarted on the new processes.
Kafka Connect process crashes
If the Kafka Connector process stops unexpectedly, any connector tasks it was running terminate without recording their most recently processed offsets. When Kafka Connect is being run in distributed mode, Kafka Connect restarts those connector tasks on other processes. However, PostgreSQL connectors resume from the last offset that was recorded by the earlier processes. This means that the new replacement tasks might generate some of the same change events that were processed just prior to the crash. The number of duplicate events depends on the offset flush period and the volume of data changes just before the crash.
Because there is a chance that some events might be duplicated during a recovery from failure, consumers should always anticipate some duplicate events. Debezium changes are idempotent, so a sequence of events always results in the same state.
In each change event record, Debezium connectors insert source-specific information about the origin of the event, including the PostgreSQL server’s time of the event, the ID of the server transaction, and the position in the write-ahead log where the transaction changes were written. Consumers can keep track of this information, especially the LSN, to determine whether an event is a duplicate.
Kafka becomes unavailable
As the connector generates change events, the Kafka Connect framework records those events in Kafka by using the Kafka producer API. Periodically, at a frequency that you specify in the Kafka Connect configuration, Kafka Connect records the latest offset that appears in those change events. If the Kafka brokers become unavailable, the Kafka Connect process that is running the connectors repeatedly tries to reconnect to the Kafka brokers. In other words, the connector tasks pause until a connection can be re-established, at which point the connectors resume exactly where they left off.
Connector is stopped for a duration
If the connector is gracefully stopped, the database can continue to be used. Any changes are recorded in the PostgreSQL WAL. When the connector restarts, it resumes streaming changes where it left off. That is, it generates change event records for all database changes that were made while the connector was stopped.
A properly configured Kafka cluster is able to handle massive throughput. Kafka Connect is written according to Kafka best practices, and given enough resources a Kafka Connect connector can also handle very large numbers of database change events. Because of this, after being stopped for a while, when a Debezium connector restarts, it is very likely to catch up with the database changes that were made while it was stopped. How quickly this happens depends on the capabilities and performance of Kafka and the volume of changes being made to the data in PostgreSQL.


Much work has been published on extracting various kinds of models from logs
that document the execution of running systems. In many cases, however, for
example in the context of evolution or testing, engineers are interested not
only in a single log but in a set of several logs, each of which originated from
a different set of runs of the system at hand. Then, the difference between the
logs is the main target of interest.
In our paper "Using Finite-State Models for Log Differencing", we investigate the use of finite-state models for log
differencing. Rather than comparing the logs directly, we generate concise
models that describe and highlight their differences. Specifically, we present
two approaches based on the classic k-Tails algorithm.
First, 2KDiff, which computes and highlights simple paths containing sequences
of k events that belong to one log but not the other. Second, nKDiff, which
extends the classic k-Tails algorithm from one log to multiple logs, and
distinguishes the sequences of length k that are common to all logs from the
ones found in only some of them, all on top of a single model. Both approaches
are sound and complete modulo the abstraction defined by the use of k-Tails.
We have implemented both approaches and evaluated their performance on
mutated logs that we have generated based on publicly available models from the
literature. we have also conducted a user study including 60 participants
demonstrating the effectiveness of the approach in log differencing tasks.
This experimental web-tool was used by the participants.
You are welcome to explore the tool yourself!


Extending¶
Creating a skin¶
The inputs and auxiliary elements are created using a set of components. The mapping can be set all together by overriding the skin.
You can take a look at skin.js and components/index.js from any skin to have a glimpse.
There’s an entry in the skin object for every field type. The value of the entry is an object with two attributes like in this example:
string: {
component: Input,
props: {
inputComponent: 'input'
}
},
component¶
The React component used to render the whole HTML for the input, including label and any other wrappers. For the Bootstrap skin the Input
component is used to do the common tasks:
string: {
component: Input
}
The component is also in charge of the field connection with redux form store (the Field
component).
Overriding¶
You can override (or add) specific types or the whole set.
-
setSkin
(skin)¶ Sets the whole skin at once.
Arguments: - skin (object) – Whole skin description
-
addSkinType
(typeName, rendering)¶ Sets the rendering for a specific schema type.
Arguments: - typeName (string) – Type name as it appears in the schema specification.
- rendering (skinTypeMap) – Object with the rendering specification.
Skin component¶
Every input component expects at least these props:
| Prop | Type | Use |
|---|---|---|
children |
element | Passed to inputComponent |
name |
string | ReduxForm field name |
fieldSchema |
object | Schema specification for the field |
schemaTypeName |
string (required) | Name of the schema that contains the field |
inputComponent |
element | Component used to render the input |
type |
string | Passed to inputComponent |
typeValidator |
function | Validator for the type. See “Override or add type validation” |
There are also other props passed depending on current implementation of renderInput
, the function in charge of choosing the component and render it.
typeValidator
is needed to avoid an error when validating field’s type. If unsure provide value => false
.
Form component¶
The form
component is different in the sense that it’s not rendered after a type. Instead, every form renders a form component in case the UI library requires special form wrapping.
InputWrap¶
It’s a common component used to create all the input structure, including wrappers. You can use it to avoid boilerplate. The final input component used (taken from inputComponent
prop) will be a decorated Field
.
| Prop | Type | Use |
|---|---|---|
children |
node | (optional) You can use InputWrap to… wrap. |
name |
string | Field name |
inputWrapper |
element | Wrapper for the input. See below for props. |
inputComponent |
element | Component receiving the input. See below for props. |
config |
object | Form configuration |
elementOnly |
boolean | (optional) Asks the wrapper to not decorate the input |
inline |
boolean | (optional) Passed to wrapper |
type |
string | (optional) Passed to input |
schemaTypeName |
string | Name of the schema as created |
onKeyDown |
function | (optional) Passed to input |
onKeyPress |
function | (optional) Passed to input |
labelOverride |
string | (optional) Passed as label to wrapper instead of |
meta |
object | ReduxForm’s meta |
The props passed to the wrapper component (inputWrapper
)
| Prop | Type | Use |
|---|---|---|
label |
string | Text use as label |
required |
boolean | Field is marked as required |
horizontal |
boolean | Taken from config |
inline |
boolean | Taken from InputWrap props |
errorMessage |
string | To print in red |
warningMessage |
string | To print in orange |
elementOnly |
boolean | Skip wrappings |
The props for the input component are different depending if the inputComponent
is a string, like 'input'
or a React component.
Common input props¶
| Prop | Type | Use |
|---|---|---|
type |
string | From InputWrap |
onKeyDown |
function | From InputWrap |
onKeyPress |
function | From InputWrap |
autoComplete |
string | Always 'off' |
placeholder |
string | From InputWrap |
Native component (ie. 'input'
)¶
For a component like that only ReduxForm input
object is passed.
Class component (ie. MySlider
)¶
Extra props are passed:
Prop # Type # Use
input
# object # From decorated Field
meta
# object # From decorated Field
config
# object # From InputWrap
from Autoform
autoFocus` # boolean # From ``InputWrap
schemaTypeName` # string # From ``Schema
Rendering¶
To feed InputWrap
with the needed props, two functions can be used:
-
renderInputs
(params)¶ Renders the inputs to make the schema work.
Arguments: - params (object) –
- params.schema (Schema) – Schema instance
- params.config (object) – Rendering configuration
- params.config.arrayMode (string) – ‘panels’ or ‘table’
- params.config.horizontal (boolean) – Labels above inputs
- params.rest (object) – Props passed to each input
Returns: array – React elements with the form and inputs.
-
renderInput
(params)¶ Renders a single field.
Arguments: - params (object) –
- params.field (string) – Name of the field
- params.fieldSchema (object) – Schema specification for the field
- params.parent (string) – Prefix of the field name
- params.schemaTypeName (string) – Name of the schema (first argument while instantiating a schema)
- params.config (object) – Form configuration
- params.rest (object) – props passed to the component
Write your own validators¶
Suppose you have a field schema and you want to add a custom validator:
const vehicles = new Schema('vehicles', {
numberOfWheels: {
type: 'number',
isEven: true
}
})
To add the validation, use
-
addValidator
(validationName, validation)¶ Adds a test creator to the testFactory table, that way you can use your own custom validations.
Arguments: - validationName (string) – The validation name for the test being created.
- validation (validatorConstructor) – Function that takes the entry and creates a validator to be used later.
That is, validation
is a function that returns a function. Outer one creates the validator and the inner one is the validator itself.
The validator returns true
when validation doesn’t pass. It can also return a translatable object or a direct message.
To implement the isEven
test using ES6 arrow functions:
import { addValidator } from 'redux-form-auto'
addValidator('isEven', entry =>
value => {
const expected = entry.isEven ? 0 : 1
return isNaN(value) || value % 2 != expected
}
)
Because the validator takes advantage of the closure from the constructor, it’s useful to write both in that cascade manner.
You can construct translatable objects using translatable()
. See Translatable objects
Override or add type validation¶
To avoid type errors as false positives you can change its behaviour in two ways:
- Adding
typeValidator
in the component definition when you create it. - Calling addSpecialTypeValidator specifying the field and the validation.
The validator has the same signature as others validators: Will receive the field’s value and returns false
for “valid”.
-
addSpecialTypeValidator
(type, validator)¶ Adds a special type validation
Arguments: - type (string) – Type validated
- validator (function) – value => true_to_fail validator


London Tea Co.
Main Navigation
Home
About
Tea
Teaware
Events
Contact
Contact
EMAIL SUPPORT
<EMAIL_ADDRESS>TO REACH SOMEONE BY PHONE
Office hours are Monday - Friday from 8:30am-4:30pm PST
Call us toll free at 1-777-888-9999
International at<PHONE_NUMBER>
Fax at<PHONE_NUMBER>
SIGN UP FOR OUR NEWSLETTER
Start
Sign up & get 10% off your first purchase


I believe in making things that matter. As an interdisciplinary designer with experience in architecture, graphic design and interaction design, my passionate and creative attitude can be seen in both digital and physical products that are functional and enjoyable. In 2008, I completed my Master's in Architecture at the University of Minnesota, specializing in conceptual design and 3D modeling. In August of 2016, I'll be completing my Master's in Human-Computer Interaction + Design at the University of Washington. My diverse work experience includes 8 years as a designer at award-winning architecture firms, along with 2 years at a small tech company, where I was a lead interaction designer.
You can find me drinking coffee, riding my bike with no hands, and occasionally building things.
Adam Riddle //<EMAIL_ADDRESS>Seattle, Washington, U.S.A.


At the end of 2018 I picked up a copy of the NOMA Fermentation Guide and was absolutely blown away by the techniques used it. It’s part cookbook, part textbook, filled to the brim with insanely awesome technical information about how the various fermentation processes work. I quickly put together a koji chamber, and started fermenting away. After making lots of koji, much of which turned into misos and shoyus, some I bartered for discounts on new knives or a free bottle of wine, I moved from Oakland to NYC and sadly sold off my chamber to some person at Lagunitas. It took some time before I finally settled in, and re-sourced a new chamber. After DM’ing multiple people on reddit with the part list, I figured I should make a website with the list and various nuances. Disclaimer: For most parts I’m using an Amazon affiliate link. If you’re trying to reduce cost, there are more than likely cheaper options out there but keep in mind the criteria for why something was picked.
First thing first, you need a container! I personally use a tray rack. It feels really versatile, especially since my girlfriend uses it when she bakes a lot of cookies. I can scale up the amount of koji being made at a time by just adding more trays. You’ll need to snag a vinyl cover and a tray for the bottom of the rack to act as the floor. Here's the link for the rack, vinyl cover, and full sized tray.
A cooler is a great starting point as they’re relatively cheap. The main caveat is you need to keep the lid slightly open most of the time to let fresh air in. Something like this would probably work really well, but if you can go to a local walmart I imagine there’s even cheaper coolers to be had. Link to Coleman cooler.
The perforation allows the Aspergillus Oryzae to breath. The hotel pans are really nice because it gives you some depth to work with, but a perforated sheet tray totally works. If you want to get fancy, you can build a traditional tray out of untreated cedar. I like half sized personally since they’re easier to handle and store. Links for the perforated sheet pan and 2 1/2” deep hotel pan.
N.B.: Sheet pans and hotel pans use fundamentally different sizing! A half sized hotel pan will not be able to use the rails in a sheet pan rack, as it's not wide enough. A full sized hotel pan will be too big. For some reason hotel pan racks are considerably more expensive than a sheet pan rack, so what I did was simply run some wood across the rails so the hotel pans can sit on them.
Most koji recipes call for lining your tray and covering your koji with a damp towel. Having an oversized tea towel or a smooth cotton towel will make life better should your rice/grain be a bit sticky, as it won't stick nearly as bad as it would to a terry cloth.
Because Aspergillus Oryzae needs to be incubated at approximately 30 degrees Celsius and at 80% humidity, you’re going to need some temperature controllers. I think the InkBird controllers work super well, especially for the price point. One thing to keep in mind though is that they are not true PID controllers, meaning there will be some temperature error. It’ll let the temperature drop to, say, 29.5 degree before turning the heating element on, and then wait until the temperature is at 30 degrees before turning it off. However, the temperature will keep rising since the heating element gives off residual heat for a short period of time, so the peak temperature is something like 31.5 degrees. Real, tuned PID controllers can keep the temperature at a consistent 30 degrees by having a model of the heating element's characteristics and constantly making micro adjustments. If you're tech inclined, you can really nerd out building your own controller using an Arduino with the relevant sensors. Link to Inkbird Humidity and Temperature controller.
Per above, you’re going to need a heating element. The size of the chamber should dictate the wattage of heater you buy. I personally use a half sized tray rack, and find 500w keeps up pretty easily at room temp. Make sure you pick one with a physical on/off switch! If it’s not physical, your heater won’t turn on when your temperature controller starts providing power to it again. Link to 500 watt space heater. For a cooler setup, you could use a heating mat to save space.
Same idea goes for a humidifier. Physical switch is a must, and chamber size dictates the amount of water you need. This will keep my chamber at 80% humidity for the whole grow time without needing to be filled, which is really nice. Link to humidifier w/ physical switch.
If you’re going to use a cooler instead of a rack style set up, you can probably use one of these small USB powered stick humidifiers in glass of water to get some space back. I haven’t tried it though so buyer beware.
N.B.: Humidity and moisture will tend to collect on the side of your chamber. This will lead to incorrect humidity readings. To get more accurate readings, I highly recommend taping the cable to the top of chamber so that the hygrometer dangles in midair, close to where your koji will be.
Once you have all your pieces, set it up! It should be pretty intuitive, make sure you keep your cord managed. If you're using a cooler, you can use something like a few mason jar lids or cooling tray to keep the koji tray off the floor.
Since I've never made a cooler based fermentation chamber, I'd strongly recommend reading /u/nesevis's post on making a cooler chamber.
Koji Alchemy is an incredible book filled with awesome recipe and knowledge, I highly recommend checking it out.
I also have a blog post on Medium about actually making koji.


Welcome to Farmie, we hope you will enjoy our products and have good experience
Far far away, behind the word mountains, far from the countries
Subtotal $20.60
Delivery $0.00
Discount $3.00
Total $17.60
Proceed to Checkout


Scope
Scope in javascript is like this place in which things exist. It is like countries and cities. For example I live in Wellington so my scope is Wellington. I do not live in Auckland so you won't find me there. If I create a new city it will have its own inhabitants similarly as a new function in javascript will have its own scope.


{{ project.title }}
{{ project.description }}
--- ---
An aspiring software engineer
Here's a bit about me:
I'm a first year student studying CS @ Waterloo. I like to design and code websites, apps, bots, games, and everything in between! This website is kinda like my personal showcase, so feel free to check out my stuff out or find me here:
Live status Last updated: Loading...
💼 Currently working on: {{ site.status.working-on }}
🎵 Current favourite song: {{ site.status.song }}
📺 Currently watching: {{ site.status.watching }}
These are some of the side projects I've worked on in my free time. Check out my GitHub for the full list!
{% for project in site.data.projects %} {% endfor %}A microblog of cool things I've done
{{ event.date }}
{{ event.desc || markdownify}}
I'm planning to add more stuff here. In the meantime here's my resume.
Certificates | School projects
A running list of websites or projects that I think are cool
{% for link in site.data.cool_links.cool_projects %} {{ link.title }} {% endfor %}