com.amazon.redshift.core.v3.replication

## Class V3RedshiftReplicationStream

- java.lang.Object
- - com.amazon.redshift.core.v3.replication.V3RedshiftReplicationStream

All Implemented Interfaces:
  RedshiftReplicationStream, AutoCloseable

    public class V3RedshiftReplicationStream
    extends Object
    implements RedshiftReplicationStream

### Field Summary

Fields
`static long` `REDSHIFT_EPOCH_2000_01_01`

### Constructor Summary

Constructors
Constructor and Description
`V3RedshiftReplicationStream(CopyDual copyDual, LogSequenceNumber startLSN, long updateIntervalMs, ReplicationType replicationType, RedshiftLogger logger)`

### Method Summary

Methods
`void` `close()` Stop replication changes from server and free resources.
`void` `forceUpdateStatus()` Force send last received, flushed and applied LSN status to backend.
`LogSequenceNumber` `getLastAppliedLSN()` Last applied lsn sent in update message to backed.
`LogSequenceNumber` `getLastFlushedLSN()` Last flushed LSN sent in update message to backend.
`LogSequenceNumber` `getLastReceiveLSN()` Parameter updates by execute `RedshiftReplicationStream.read()` method.
`boolean` `isClosed()`
`ByteBuffer` `read()` Read next wal record from backend.
`ByteBuffer` `readPending()` Read next WAL record from backend.
`void` `setAppliedLSN(LogSequenceNumber applied)` Inform backend which LSN has been applied on standby.
`void` `setFlushedLSN(LogSequenceNumber flushed)` Set flushed LSN.

### Methods inherited from class java.lang.Object

`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

### Field Detail

#### REDSHIFT_EPOCH_2000_01_01

    public static final long REDSHIFT_EPOCH_2000_01_01

See Also:
  Constant Field Values

### Constructor Detail

#### V3RedshiftReplicationStream

    public V3RedshiftReplicationStream(CopyDual copyDual,
                               LogSequenceNumber startLSN,
                               long updateIntervalMs,
                               ReplicationType replicationType,
                               RedshiftLogger logger)

Parameters:
  `copyDual` - bidirectional copy protocol
  `startLSN` - the position in the WAL that we want to initiate replication from usually the currentLSN returned by calling pg_current_wal_lsn()for v10 above or pg_current_xlog_location() depending on the version of the server
  `updateIntervalMs` - the number of millisecond between status packets sent back to the server. A value of zero disables the periodic status updates completely, although an update will still be sent when requested by the server, to avoid timeout disconnect.
  `replicationType` - LOGICAL or PHYSICAL
  `logger` - the logger to log the entry for debugging.

### Method Detail

#### read

    public ByteBuffer read()
                    throws SQLException

Description copied from interface: `RedshiftReplicationStream`

Read next wal record from backend. It method can be block until new message will not get from server.

A single WAL record is never split across two XLogData messages. When a WAL record crosses a WAL page boundary, and is therefore already split using continuation records, it can be split at the page boundary. In other words, the first main WAL record and its continuation records can be sent in different XLogData messages.

Specified by:
  `read` in interface `RedshiftReplicationStream`
Returns:
  not null byte array received by replication protocol, return ByteBuffer wrap around received byte array with use offset, so, use `ByteBuffer.array()` carefully
Throws:
  `SQLException` - when some internal exception occurs during read from stream

#### readPending

    public ByteBuffer readPending()
                           throws SQLException

Description copied from interface: `RedshiftReplicationStream`

Read next WAL record from backend. This method does not block and in contrast to `RedshiftReplicationStream.read()`. If message from backend absent return null. It allow periodically check message in stream and if they absent sleep some time, but it time should be less than `CommonOptions.getStatusInterval()` to avoid disconnect from the server.

A single WAL record is never split across two XLogData messages. When a WAL record crosses a WAL page boundary, and is therefore already split using continuation records, it can be split at the page boundary. In other words, the first main WAL record and its continuation records can be sent in different XLogData messages.

Specified by:
  `readPending` in interface `RedshiftReplicationStream`
Returns:
  byte array received by replication protocol or NULL if pending message from server absent. Returns ByteBuffer wrap around received byte array with use offset, so, use `ByteBuffer.array()` carefully.
Throws:
  `SQLException` - when some internal exception occurs during read from stream

#### getLastReceiveLSN

    public LogSequenceNumber getLastReceiveLSN()

Description copied from interface: `RedshiftReplicationStream`

Parameter updates by execute `RedshiftReplicationStream.read()` method.

It is safe to call this method in a thread different than the main thread. However, usually this method is called in the main thread after a successful `RedshiftReplicationStream.read()` or `RedshiftReplicationStream.readPending()`, to get the LSN corresponding to the received record.

Specified by:
  `getLastReceiveLSN` in interface `RedshiftReplicationStream`
Returns:
  NOT NULL LSN position that was receive last time via `RedshiftReplicationStream.read()` method

#### getLastFlushedLSN

    public LogSequenceNumber getLastFlushedLSN()

Description copied from interface: `RedshiftReplicationStream`

Last flushed LSN sent in update message to backend. Parameter updates only via `RedshiftReplicationStream.setFlushedLSN(LogSequenceNumber)`

It is safe to call this method in a thread different than the main thread.

Specified by:
  `getLastFlushedLSN` in interface `RedshiftReplicationStream`
Returns:
  NOT NULL location of the last WAL flushed to disk in the standby.

#### getLastAppliedLSN

    public LogSequenceNumber getLastAppliedLSN()

Description copied from interface: `RedshiftReplicationStream`

Last applied lsn sent in update message to backed. Parameter updates only via `RedshiftReplicationStream.setAppliedLSN(LogSequenceNumber)`

It is safe to call this method in a thread different than the main thread.

Specified by:
  `getLastAppliedLSN` in interface `RedshiftReplicationStream`
Returns:
  not null location of the last WAL applied in the standby.

#### setFlushedLSN

    public void setFlushedLSN(LogSequenceNumber flushed)

Description copied from interface: `RedshiftReplicationStream`

Set flushed LSN. This parameter will be sent to backend on next update status iteration. Flushed LSN position help backend define which WAL can be recycled.

It is safe to call this method in a thread different than the main thread. The updated value will be sent to the backend in the next status update run.

Specified by:
  `setFlushedLSN` in interface `RedshiftReplicationStream`
Parameters:
  `flushed` - NOT NULL location of the last WAL flushed to disk in the standby.
See Also:
  `RedshiftReplicationStream.forceUpdateStatus()`

#### setAppliedLSN

    public void setAppliedLSN(LogSequenceNumber applied)

Description copied from interface: `RedshiftReplicationStream`

Inform backend which LSN has been applied on standby. Feedback will send to backend on next update status iteration.

It is safe to call this method in a thread different than the main thread. The updated value will be sent to the backend in the next status update run.

Specified by:
  `setAppliedLSN` in interface `RedshiftReplicationStream`
Parameters:
  `applied` - NOT NULL location of the last WAL applied in the standby.
See Also:
  `RedshiftReplicationStream.forceUpdateStatus()`

#### forceUpdateStatus

    public void forceUpdateStatus()
                           throws SQLException

Description copied from interface: `RedshiftReplicationStream`
Force send last received, flushed and applied LSN status to backend. You cannot send LSN status explicitly because `RedshiftReplicationStream` sends the status to backend periodically by configured interval via `CommonOptions.getStatusInterval()`

Specified by:
  `forceUpdateStatus` in interface `RedshiftReplicationStream`
Throws:
  `SQLException` - when some internal exception occurs during read from stream
See Also:
  `CommonOptions.getStatusInterval()`

#### isClosed

    public boolean isClosed()

Specified by:
  `isClosed` in interface `RedshiftReplicationStream`
Returns:
  `true` if replication stream was already close, otherwise return `false`

#### close

    public void close()
               throws SQLException

Description copied from interface: `RedshiftReplicationStream`

Stop replication changes from server and free resources. After that connection can be reuse to another queries. Also after close current stream they cannot be used anymore.

Note: This method can spend much time for logical replication stream on Redshift version 9.6 and lower, because Redshift have bug - during decode big transaction to logical form and during wait new changes Redshift ignore messages from client. As workaround you can close replication connection instead of close replication stream. For more information about it problem see mailing list thread Stopping logical replication protocol

Specified by:
  `close` in interface `RedshiftReplicationStream`
Specified by:
  `close` in interface `AutoCloseable`
Throws:
  `SQLException` - when some internal exception occurs during end streaming