Indexing & updates

A single UpdateRequestHandler, registered at /update, accepts XML, JSON, CSV, or javabin and picks the right content-stream loader from the request’s Content-Type header. Two extra paths exist purely as a convenience so you don’t have to set that header by hand:

Every request can carry update commands, not just documents: add, delete (by id or by query), commit, optimize, and rollback. The JSON/XML/CSV shapes below are three ways to say the same thing; see Indexing with Update Handlers for the complete command reference.

bin/solr post wraps the same /update handler for command-line and scripted loads — files, directories, a whole tree of mixed formats, standard input, raw content, or even a shallow website crawl — and is explicitly the tool for getting-started and ad hoc loading, not a production indexing pipeline (it has no retry/backpressure handling of its own).

Getting Started’s first round-trip uses plain curl for the single-document case and the Post Tool for bulk sample data — that split holds across this section.

SolrJ builds a SolrInputDocument field-by-field and sends it with SolrClient.add, which is the programmatic equivalent of a JSON/XML add command — no HTTP body to construct by hand, and errors come back as a typed SolrServerException/SolrException instead of a status code to parse.

Batching many documents into one add call amortizes the network round trip the same way the _bulk API does for Elasticsearch; a List<SolrInputDocument> overload of add takes the whole batch in one request.

Every update request — however it arrived, over any of the endpoints above — runs through an ordered update request processor (URP) chain before it is applied: a pipeline of small, composable steps such as logging, distributing the write to the right shard/replica, deduplicating, adding a field, or rejecting a malformed document. The default chain (LogUpdateProcessorFactory → DistributedUpdateProcessorFactory → RunUpdateProcessorFactory) is what actually performs the add; a custom chain, named in solrconfig.xml, inserts extra processors before that point.

A chain can also be built on the fly from request parameters instead of being predeclared, which is useful for a one-off backfill that needs a processor no permanent chain has. See Update Request Processors for the full factory catalogue — field mutation, deduplication, language detection, and script-based processors among them.

Everything above assumes the caller already has field-shaped data. For binary formats — PDF, Word, Excel, and the rest — the ExtractingRequestHandler ("Solr Cell") sends the file to an Apache Tika server, which extracts text and metadata and hands back XHTML that Solr Cell maps onto fields, same as any other add.

fmap.<source>=<field> renames an extracted field, uprefix=ignored_ catches everything not explicitly mapped instead of erroring on an unknown field, and capture pulls specific embedded elements out separately. See Indexing with Solr Cell and Apache Tika for the parameter reference, running the Tika server, and encrypted-document handling. Solr Cell is meant for moderate document volumes at index time, not as a general-purpose document-conversion service for the rest of your application.

The Data Import Handler (DIH) — the old built-in tool for pulling documents straight from a JDBC database, a flat file, or an XML/HTTP source on a schedule — was removed from Solr’s core distribution (Solr 9.0) and is not bundled with Solr anymore. It survives only as a separately-installed, community-maintained package: install it explicitly (through Solr’s package manager or by dropping its jar on the classpath) before referencing a DIH handler in solrconfig.xml, and treat it as an optional add-on with its own release cadence and support, not a guaranteed-present core feature. Do not assume a fresh Solr install can run a DIH data-config.xml out of the box.

With DIH no longer built in, the common pattern for keeping Solr’s index current with a database (or another system of record) is an external pipeline: a scheduled batch job, a change-data-capture (CDC) stream (e.g. Debezium reading a database’s replication log), or a message-queue consumer that translates each insert/update/delete into a call against the endpoints on this page — SolrInputDocument`s over SolrJ, or JSON/CSV over `/update — rather than a Solr-embedded pull job. This mirrors how the same problem is solved for Elasticsearch’s own ingest layer: business logic and source-system access live in a general-purpose tool outside the search engine, and Solr’s own job stays limited to receiving well-formed documents and answering queries fast. Choose commitWithin (a single add) or a scheduled autoSoftCommit (a steady stream) so the sync job does not have to manage commits itself — see the next section.

A document is durable-in-the-log the moment /update accepts it, but invisible to search until a commit opens a new (or reopened) searcher. Solr has two kinds, and they answer different questions: "is this safe on disk" and "can a query see it yet."

The transaction log (tlog) is a durable, append-only record of every add/delete Solr has accepted since the last hard commit — the write-ahead log that makes a hard commit’s fsync safe to defer and is what a recovering or newly-added replica replays to catch up without a full index copy.

A hard commit truncates the tlog once its contents are safely in fsynced segments; a soft commit does not touch it at all, which is exactly why soft commits alone are not a durability guarantee — an unclean shutdown between hard commits replays whatever the tlog still holds on restart. See Commits and Transaction Logs for tlog sizing (numRecordsToKeep, maxNumLogsToKeep) and replica-recovery behavior.

GET /solr/<collection>/get?id=<id> answers "what is the current value of this document right now," reading straight from the transaction log (or the in-memory update log) when the document has not reached a searcher yet, and from the index otherwise — so it sees a write a /select query issued the same instant would not. It needs no commit at all.

RealTime Get is what lets an application use Solr like a key-value store for "read your own write" checks even while running commits on a relaxed schedule — and it is also load-bearing for SolrCloud itself: disabling the /get handler forces every leader election and replica recovery into a full index copy instead of a partial sync, so leave it enabled. See RealTime Get for the handler configuration and its interaction with atomic updates, covered in depth on Partial updates & concurrency.

Continue with Partial updates & concurrency for atomic field updates and optimistic concurrency on documents already in the index, or Indexing internals & performance for tuning bulk-load throughput.