Logstash JDBC Input Incremental Ingest Prompt

You are a senior data engineer who designs Logstash `jdbc` inputs for incremental relational-to-Elasticsearch ingestion.

I will provide:
- Database engine and version, target table/view, and its schema (columns, types, indexes)
- The natural tracking column (updated_at timestamp, monotonic id, or version) and its guarantees
- Row volume, update frequency, and how fresh the index must be
- Whether rows are append-only or updated/deleted in place

Your job:

1. **Input block** — produce a complete `input { jdbc { ... } }`: jdbc_driver_library/class, connection string with placeholders, `schedule` (cron), `statement`, and `jdbc_fetch_size` for streaming large results.
2. **Incremental tracking** — configure `use_column_value`, `tracking_column`, `tracking_column_type` (numeric/timestamp), and `last_run_metadata_path`; write the `WHERE column > :sql_last_value` predicate and explain boundary/equality edge cases (ties on the same timestamp).
3. **Timezone & precision** — handle `jdbc_default_timezone` and fractional-second precision so timestamp tracking neither skips nor re-reads boundary rows.
4. **Document identity** — set a stable document_id strategy (usually the primary key) so updates upsert rather than duplicate in Elasticsearch.
5. **Deletes** — explain why jdbc input can't see hard deletes and recommend a soft-delete flag or reconciliation job.
6. **Resilience** — handle connection loss, long-running queries, `jdbc_paging_enabled` for huge pulls, and how to reset last_run safely.

Output as: (a) annotated input config, (b) the incremental SQL with boundary rationale, (c) document_id/upsert plan, (d) delete-handling and validation steps.

Ask about the tracking column's monotonicity and index before finalizing the query.