ClickHouse DB::Exception: Table is in readonly mode

Pulse - Elasticsearch Operations Done Right

On this page

Impact Common Causes Troubleshooting and Resolution Steps Best Practices Frequently Asked Questions

The "DB::Exception: Table is in readonly mode" error in ClickHouse occurs when an attempt is made to modify a table that is currently set to read-only mode. This prevents any write operations, including INSERT, UPDATE, or DELETE queries, from being executed on the affected table.

Impact

This error can significantly impact data operations and application functionality. It prevents any modifications to the table data, potentially disrupting data ingestion processes, update routines, or any other write operations that your application may rely on.

Common Causes

  1. The table was explicitly set to read-only mode using ALTER TABLE ... MODIFY SETTING read_only = 1.
  2. The entire database or ClickHouse instance is in read-only mode.
  3. Disk space issues causing ClickHouse to switch to read-only mode for data protection.
  4. Replication issues in a distributed ClickHouse setup.
  5. User permissions are set to read-only for the specific table or database.

Troubleshooting and Resolution Steps

  1. Check table settings:

    SHOW CREATE TABLE database_name.table_name;
    

    Look for the read_only setting in the output.

  2. If the table is set to read-only, change it back:

    ALTER TABLE database_name.table_name MODIFY SETTING read_only = 0;
    
  3. Verify database and server read-only status:

    SELECT * FROM system.databases WHERE name = 'your_database_name';
    SELECT * FROM system.settings WHERE name = 'readonly';
    
  4. Check disk space:

    SELECT * FROM system.disks;
    

    Ensure there's sufficient free space on all disks.

  5. For replication issues, check the replication status:

    SELECT * FROM system.replication_queue;
    

    Address any replication lags or errors.

  6. Verify user permissions:

    SHOW GRANTS FOR current_user();
    

    Ensure the user has the necessary write permissions.

Best Practices

  1. Regularly monitor disk space and set up alerts for low disk space conditions.
  2. Implement proper user access controls and regularly audit permissions.
  3. For critical tables, consider setting up monitoring for unexpected read-only mode changes.
  4. In replicated setups, ensure proper monitoring of replication health and lag.

Frequently Asked Questions

Q: Can I query a table that is in read-only mode?
A: Yes, you can still perform SELECT queries on a table in read-only mode. Only write operations are restricted.

Q: How can I prevent tables from accidentally being set to read-only mode?
A: Implement strict access controls, limiting the ability to modify table settings to authorized personnel only. Also, set up monitoring for changes to critical table settings.

Q: Will restarting the ClickHouse server resolve the read-only mode issue?
A: Not necessarily. If the read-only mode was set due to configuration or explicit table settings, a restart won't change it. However, if it was due to a temporary condition like low disk space, resolving the underlying issue and restarting might help.

Q: Can read-only mode affect only specific columns in a table?
A: No, the read-only mode is applied at the table level. It's not possible to set only specific columns to read-only while allowing writes to others within the same table.

Q: How does read-only mode interact with distributed tables in ClickHouse?
A: If a local table on one of the shards is in read-only mode, it will affect write operations to the distributed table that involves that shard. Read operations across the distributed table will still work, but writes may fail or be incomplete.

Subscribe to the Pulse Newsletter

Get early access to new Pulse features, insightful blogs & exclusive events , webinars, and workshops.