2017-02-26 22:38:06 +00:00
|
|
|
"""SQLAlchemy util functions."""
|
2021-03-11 17:52:07 +00:00
|
|
|
from __future__ import annotations
|
|
|
|
|
|
|
|
from collections.abc import Generator
|
2017-02-26 22:38:06 +00:00
|
|
|
from contextlib import contextmanager
|
2020-08-21 12:20:46 +00:00
|
|
|
from datetime import timedelta
|
2021-05-16 17:23:37 +00:00
|
|
|
import functools
|
2017-02-26 22:38:06 +00:00
|
|
|
import logging
|
2020-07-18 05:07:37 +00:00
|
|
|
import os
|
2017-02-26 22:38:06 +00:00
|
|
|
import time
|
2021-07-13 19:21:45 +00:00
|
|
|
from typing import TYPE_CHECKING, Callable
|
2017-02-26 22:38:06 +00:00
|
|
|
|
2019-10-18 17:14:54 +00:00
|
|
|
from sqlalchemy.exc import OperationalError, SQLAlchemyError
|
2021-03-11 17:52:07 +00:00
|
|
|
from sqlalchemy.orm.session import Session
|
2019-10-18 17:14:54 +00:00
|
|
|
|
2021-04-22 17:58:02 +00:00
|
|
|
from homeassistant.core import HomeAssistant
|
2020-07-18 05:07:37 +00:00
|
|
|
import homeassistant.util.dt as dt_util
|
|
|
|
|
2021-04-12 06:43:54 +00:00
|
|
|
from .const import DATA_INSTANCE, SQLITE_URL_PREFIX
|
|
|
|
from .models import (
|
|
|
|
ALL_TABLES,
|
|
|
|
TABLE_RECORDER_RUNS,
|
|
|
|
TABLE_SCHEMA_CHANGES,
|
2021-05-16 17:23:37 +00:00
|
|
|
TABLE_STATISTICS,
|
2021-06-30 11:32:17 +00:00
|
|
|
TABLE_STATISTICS_META,
|
2021-04-19 15:22:38 +00:00
|
|
|
RecorderRuns,
|
2021-04-12 06:43:54 +00:00
|
|
|
process_timestamp,
|
|
|
|
)
|
2017-02-26 22:38:06 +00:00
|
|
|
|
2021-05-16 17:23:37 +00:00
|
|
|
if TYPE_CHECKING:
|
|
|
|
from . import Recorder
|
|
|
|
|
2017-02-26 22:38:06 +00:00
|
|
|
_LOGGER = logging.getLogger(__name__)
|
|
|
|
|
|
|
|
RETRIES = 3
|
|
|
|
QUERY_RETRY_WAIT = 0.1
|
2020-07-18 05:07:37 +00:00
|
|
|
SQLITE3_POSTFIXES = ["", "-wal", "-shm"]
|
2017-02-26 22:38:06 +00:00
|
|
|
|
2020-08-21 12:20:46 +00:00
|
|
|
# This is the maximum time after the recorder ends the session
|
|
|
|
# before we no longer consider startup to be a "restart" and we
|
|
|
|
# should do a check on the sqlite3 database.
|
2020-09-02 08:12:56 +00:00
|
|
|
MAX_RESTART_TIME = timedelta(minutes=10)
|
2020-08-21 12:20:46 +00:00
|
|
|
|
2021-05-16 17:23:37 +00:00
|
|
|
# Retry when one of the following MySQL errors occurred:
|
|
|
|
RETRYABLE_MYSQL_ERRORS = (1205, 1206, 1213)
|
|
|
|
# 1205: Lock wait timeout exceeded; try restarting transaction
|
|
|
|
# 1206: The total number of locks exceeds the lock table size
|
|
|
|
# 1213: Deadlock found when trying to get lock; try restarting transaction
|
|
|
|
|
2017-02-26 22:38:06 +00:00
|
|
|
|
|
|
|
@contextmanager
|
2021-03-11 17:52:07 +00:00
|
|
|
def session_scope(
|
2021-04-22 17:58:02 +00:00
|
|
|
*, hass: HomeAssistant | None = None, session: Session | None = None
|
2021-03-11 17:52:07 +00:00
|
|
|
) -> Generator[Session, None, None]:
|
2017-02-26 22:38:06 +00:00
|
|
|
"""Provide a transactional scope around a series of operations."""
|
|
|
|
if session is None and hass is not None:
|
|
|
|
session = hass.data[DATA_INSTANCE].get_session()
|
|
|
|
|
|
|
|
if session is None:
|
2019-07-31 19:25:30 +00:00
|
|
|
raise RuntimeError("Session required")
|
2017-02-26 22:38:06 +00:00
|
|
|
|
2019-03-09 20:04:13 +00:00
|
|
|
need_rollback = False
|
2017-02-26 22:38:06 +00:00
|
|
|
try:
|
|
|
|
yield session
|
2021-04-22 06:29:36 +00:00
|
|
|
if session.get_transaction():
|
2019-03-09 20:04:13 +00:00
|
|
|
need_rollback = True
|
|
|
|
session.commit()
|
2019-11-26 06:40:08 +00:00
|
|
|
except Exception as err:
|
2017-05-02 16:18:47 +00:00
|
|
|
_LOGGER.error("Error executing query: %s", err)
|
2019-03-09 20:04:13 +00:00
|
|
|
if need_rollback:
|
|
|
|
session.rollback()
|
2017-02-26 22:38:06 +00:00
|
|
|
raise
|
|
|
|
finally:
|
|
|
|
session.close()
|
|
|
|
|
|
|
|
|
|
|
|
def commit(session, work):
|
|
|
|
"""Commit & retry work: Either a model or in a function."""
|
|
|
|
for _ in range(0, RETRIES):
|
|
|
|
try:
|
|
|
|
if callable(work):
|
|
|
|
work(session)
|
|
|
|
else:
|
|
|
|
session.add(work)
|
|
|
|
session.commit()
|
|
|
|
return True
|
2019-10-18 17:14:54 +00:00
|
|
|
except OperationalError as err:
|
2017-05-02 16:18:47 +00:00
|
|
|
_LOGGER.error("Error executing query: %s", err)
|
2017-02-26 22:38:06 +00:00
|
|
|
session.rollback()
|
|
|
|
time.sleep(QUERY_RETRY_WAIT)
|
|
|
|
return False
|
|
|
|
|
|
|
|
|
2021-07-13 19:21:45 +00:00
|
|
|
def execute(qry, to_native=False, validate_entity_ids=True) -> list | None:
|
2017-02-26 22:38:06 +00:00
|
|
|
"""Query the database and convert the objects to HA native form.
|
|
|
|
|
|
|
|
This method also retries a few times in the case of stale connections.
|
|
|
|
"""
|
2020-07-18 05:07:37 +00:00
|
|
|
|
2017-02-26 22:38:06 +00:00
|
|
|
for tryno in range(0, RETRIES):
|
|
|
|
try:
|
History query and schema optimizations for huge performance boost (#8748)
* Add DEBUG-level log for db row to native object conversion
This is now the bottleneck (by a large margin) for big history queries, so I'm leaving this log feature in to help diagnose users with a slow history page
* Rewrite of the "first synthetic datapoint" query for multiple entities
The old method was written in a manner that prevented an index from being used in the inner-most GROUP BY statement, causing massive performance issues especially when querying for a large time period.
The new query does have one material change that will cause it to return different results than before: instead of using max(state_id) to get the latest entry, we now get the max(last_updated). This is more appropriate (primary key should not be assumed to be in order of event firing) and allows an index to be used on the inner-most query. I added another JOIN layer to account for cases where there are two entries on the exact same `last_created` for a given entity. In this case we do use `state_id` as a tiebreaker.
For performance reasons the domain filters were also moved to the outermost query, as it's way more efficient to do it there than on the innermost query as before (due to indexing with GROUP BY problems)
The result is a query that only needs to do a filesort on the final result set, which will only be as many rows as there are entities.
* Remove the ORDER BY entity_id when fetching states, and add logging
Having this ORDER BY in the query prevents it from using an index due to the range filter, so it has been removed.
We already do a `groupby` in the `states_to_json` method which accomplishes exactly what the ORDER BY in the query was trying to do anyway, so this change causes no functional difference.
Also added DEBUG-level logging to allow diagnosing a user's slow history page.
* Add DEBUG-level logging for the synthetic-first-datapoint query
For diagnosing a user's slow history page
* Missed a couple instances of `created` that should be `last_updated`
* Remove `entity_id` sorting from state_changes; match significant_update
This is the same change as 09b3498f410106881fc5e095c49a8d527fa89644 , but applied to the `state_changes_during_period` method which I missed before. This should give the same performance boost to the history sensor component!
* Bugfix in History query used for History Sensor
The date filter was using a different column for the upper and lower bounds. It would work, but it would be slow!
* Update Recorder purge script to use more appropriate columns
Two reasons: 1. the `created` column's meaning is fairly arbitrary and does not represent when an event or state change actually ocurred. It seems more correct to purge based on the event date than the time the database row was written.
2. The new columns are indexed, which will speed up this purge script by orders of magnitude
* Updating db model to match new query optimizations
A few things here: 1. New schema version with a new index and several removed indexes
2. A new method in the migration script to drop old indexes
3. Added an INFO-level log message when a new index will be added, as this can take quite some time on a Raspberry Pi
2017-08-05 06:16:53 +00:00
|
|
|
timer_start = time.perf_counter()
|
Improve history api performance (#35822)
* Improve history api performance
A new option "minimal_response" reduces the amount of data
sent between the first and last history states to only the
"last_changed" and "state" fields.
Calling to_native is now avoided where possible and only
done at the end for rows that will be returned in the response.
When sending the `minimal_response` option, the history
api now returns a json response similar to the following
for an entity
Testing:
History API Response time for 1 day
Average of 10 runs with minimal_response
Before: 19.89s. (content length : 3427428)
After: 8.44s (content length: 592199)
```
[{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-18T23:20:03.213000+00:00",
"last_updated": "2020-05-18T23:20:03.213000+00:00",
"state": "on"
},
...
{
"last_changed": "2020-05-19T00:41:08Z",
"state": "unavailable"
},
...
{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-19T00:42:08.069698+00:00",
"last_updated": "2020-05-19T00:42:08.069698+00:00",
"state": "on"
}]
```
* Remove impossible state check
* Remove another impossible state check
* Update homeassistant/components/history/__init__.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Reorder to save some indent per review
* Make query response make sense with to_native=False
* Update test for 00:00 to Z change
* Update homeassistant/components/recorder/models.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
2020-05-27 02:53:56 +00:00
|
|
|
if to_native:
|
|
|
|
result = [
|
2020-06-22 04:58:57 +00:00
|
|
|
row
|
|
|
|
for row in (
|
|
|
|
row.to_native(validate_entity_id=validate_entity_ids)
|
|
|
|
for row in qry
|
|
|
|
)
|
|
|
|
if row is not None
|
Improve history api performance (#35822)
* Improve history api performance
A new option "minimal_response" reduces the amount of data
sent between the first and last history states to only the
"last_changed" and "state" fields.
Calling to_native is now avoided where possible and only
done at the end for rows that will be returned in the response.
When sending the `minimal_response` option, the history
api now returns a json response similar to the following
for an entity
Testing:
History API Response time for 1 day
Average of 10 runs with minimal_response
Before: 19.89s. (content length : 3427428)
After: 8.44s (content length: 592199)
```
[{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-18T23:20:03.213000+00:00",
"last_updated": "2020-05-18T23:20:03.213000+00:00",
"state": "on"
},
...
{
"last_changed": "2020-05-19T00:41:08Z",
"state": "unavailable"
},
...
{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-19T00:42:08.069698+00:00",
"last_updated": "2020-05-19T00:42:08.069698+00:00",
"state": "on"
}]
```
* Remove impossible state check
* Remove another impossible state check
* Update homeassistant/components/history/__init__.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Reorder to save some indent per review
* Make query response make sense with to_native=False
* Update test for 00:00 to Z change
* Update homeassistant/components/recorder/models.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
2020-05-27 02:53:56 +00:00
|
|
|
]
|
|
|
|
else:
|
|
|
|
result = list(qry)
|
History query and schema optimizations for huge performance boost (#8748)
* Add DEBUG-level log for db row to native object conversion
This is now the bottleneck (by a large margin) for big history queries, so I'm leaving this log feature in to help diagnose users with a slow history page
* Rewrite of the "first synthetic datapoint" query for multiple entities
The old method was written in a manner that prevented an index from being used in the inner-most GROUP BY statement, causing massive performance issues especially when querying for a large time period.
The new query does have one material change that will cause it to return different results than before: instead of using max(state_id) to get the latest entry, we now get the max(last_updated). This is more appropriate (primary key should not be assumed to be in order of event firing) and allows an index to be used on the inner-most query. I added another JOIN layer to account for cases where there are two entries on the exact same `last_created` for a given entity. In this case we do use `state_id` as a tiebreaker.
For performance reasons the domain filters were also moved to the outermost query, as it's way more efficient to do it there than on the innermost query as before (due to indexing with GROUP BY problems)
The result is a query that only needs to do a filesort on the final result set, which will only be as many rows as there are entities.
* Remove the ORDER BY entity_id when fetching states, and add logging
Having this ORDER BY in the query prevents it from using an index due to the range filter, so it has been removed.
We already do a `groupby` in the `states_to_json` method which accomplishes exactly what the ORDER BY in the query was trying to do anyway, so this change causes no functional difference.
Also added DEBUG-level logging to allow diagnosing a user's slow history page.
* Add DEBUG-level logging for the synthetic-first-datapoint query
For diagnosing a user's slow history page
* Missed a couple instances of `created` that should be `last_updated`
* Remove `entity_id` sorting from state_changes; match significant_update
This is the same change as 09b3498f410106881fc5e095c49a8d527fa89644 , but applied to the `state_changes_during_period` method which I missed before. This should give the same performance boost to the history sensor component!
* Bugfix in History query used for History Sensor
The date filter was using a different column for the upper and lower bounds. It would work, but it would be slow!
* Update Recorder purge script to use more appropriate columns
Two reasons: 1. the `created` column's meaning is fairly arbitrary and does not represent when an event or state change actually ocurred. It seems more correct to purge based on the event date than the time the database row was written.
2. The new columns are indexed, which will speed up this purge script by orders of magnitude
* Updating db model to match new query optimizations
A few things here: 1. New schema version with a new index and several removed indexes
2. A new method in the migration script to drop old indexes
3. Added an INFO-level log message when a new index will be added, as this can take quite some time on a Raspberry Pi
2017-08-05 06:16:53 +00:00
|
|
|
|
|
|
|
if _LOGGER.isEnabledFor(logging.DEBUG):
|
|
|
|
elapsed = time.perf_counter() - timer_start
|
Improve history api performance (#35822)
* Improve history api performance
A new option "minimal_response" reduces the amount of data
sent between the first and last history states to only the
"last_changed" and "state" fields.
Calling to_native is now avoided where possible and only
done at the end for rows that will be returned in the response.
When sending the `minimal_response` option, the history
api now returns a json response similar to the following
for an entity
Testing:
History API Response time for 1 day
Average of 10 runs with minimal_response
Before: 19.89s. (content length : 3427428)
After: 8.44s (content length: 592199)
```
[{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-18T23:20:03.213000+00:00",
"last_updated": "2020-05-18T23:20:03.213000+00:00",
"state": "on"
},
...
{
"last_changed": "2020-05-19T00:41:08Z",
"state": "unavailable"
},
...
{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-19T00:42:08.069698+00:00",
"last_updated": "2020-05-19T00:42:08.069698+00:00",
"state": "on"
}]
```
* Remove impossible state check
* Remove another impossible state check
* Update homeassistant/components/history/__init__.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Reorder to save some indent per review
* Make query response make sense with to_native=False
* Update test for 00:00 to Z change
* Update homeassistant/components/recorder/models.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
2020-05-27 02:53:56 +00:00
|
|
|
if to_native:
|
|
|
|
_LOGGER.debug(
|
|
|
|
"converting %d rows to native objects took %fs",
|
|
|
|
len(result),
|
|
|
|
elapsed,
|
|
|
|
)
|
|
|
|
else:
|
|
|
|
_LOGGER.debug(
|
2020-08-27 11:56:20 +00:00
|
|
|
"querying %d rows took %fs",
|
|
|
|
len(result),
|
|
|
|
elapsed,
|
Improve history api performance (#35822)
* Improve history api performance
A new option "minimal_response" reduces the amount of data
sent between the first and last history states to only the
"last_changed" and "state" fields.
Calling to_native is now avoided where possible and only
done at the end for rows that will be returned in the response.
When sending the `minimal_response` option, the history
api now returns a json response similar to the following
for an entity
Testing:
History API Response time for 1 day
Average of 10 runs with minimal_response
Before: 19.89s. (content length : 3427428)
After: 8.44s (content length: 592199)
```
[{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-18T23:20:03.213000+00:00",
"last_updated": "2020-05-18T23:20:03.213000+00:00",
"state": "on"
},
...
{
"last_changed": "2020-05-19T00:41:08Z",
"state": "unavailable"
},
...
{
"attributes": {--TRUNCATED--},
"context": {--TRUNCATED--},
"entity_id": "binary_sensor.powerwall_status",
"last_changed": "2020-05-19T00:42:08.069698+00:00",
"last_updated": "2020-05-19T00:42:08.069698+00:00",
"state": "on"
}]
```
* Remove impossible state check
* Remove another impossible state check
* Update homeassistant/components/history/__init__.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Reorder to save some indent per review
* Make query response make sense with to_native=False
* Update test for 00:00 to Z change
* Update homeassistant/components/recorder/models.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
2020-05-27 02:53:56 +00:00
|
|
|
)
|
History query and schema optimizations for huge performance boost (#8748)
* Add DEBUG-level log for db row to native object conversion
This is now the bottleneck (by a large margin) for big history queries, so I'm leaving this log feature in to help diagnose users with a slow history page
* Rewrite of the "first synthetic datapoint" query for multiple entities
The old method was written in a manner that prevented an index from being used in the inner-most GROUP BY statement, causing massive performance issues especially when querying for a large time period.
The new query does have one material change that will cause it to return different results than before: instead of using max(state_id) to get the latest entry, we now get the max(last_updated). This is more appropriate (primary key should not be assumed to be in order of event firing) and allows an index to be used on the inner-most query. I added another JOIN layer to account for cases where there are two entries on the exact same `last_created` for a given entity. In this case we do use `state_id` as a tiebreaker.
For performance reasons the domain filters were also moved to the outermost query, as it's way more efficient to do it there than on the innermost query as before (due to indexing with GROUP BY problems)
The result is a query that only needs to do a filesort on the final result set, which will only be as many rows as there are entities.
* Remove the ORDER BY entity_id when fetching states, and add logging
Having this ORDER BY in the query prevents it from using an index due to the range filter, so it has been removed.
We already do a `groupby` in the `states_to_json` method which accomplishes exactly what the ORDER BY in the query was trying to do anyway, so this change causes no functional difference.
Also added DEBUG-level logging to allow diagnosing a user's slow history page.
* Add DEBUG-level logging for the synthetic-first-datapoint query
For diagnosing a user's slow history page
* Missed a couple instances of `created` that should be `last_updated`
* Remove `entity_id` sorting from state_changes; match significant_update
This is the same change as 09b3498f410106881fc5e095c49a8d527fa89644 , but applied to the `state_changes_during_period` method which I missed before. This should give the same performance boost to the history sensor component!
* Bugfix in History query used for History Sensor
The date filter was using a different column for the upper and lower bounds. It would work, but it would be slow!
* Update Recorder purge script to use more appropriate columns
Two reasons: 1. the `created` column's meaning is fairly arbitrary and does not represent when an event or state change actually ocurred. It seems more correct to purge based on the event date than the time the database row was written.
2. The new columns are indexed, which will speed up this purge script by orders of magnitude
* Updating db model to match new query optimizations
A few things here: 1. New schema version with a new index and several removed indexes
2. A new method in the migration script to drop old indexes
3. Added an INFO-level log message when a new index will be added, as this can take quite some time on a Raspberry Pi
2017-08-05 06:16:53 +00:00
|
|
|
|
|
|
|
return result
|
2017-02-26 22:38:06 +00:00
|
|
|
except SQLAlchemyError as err:
|
2017-05-02 16:18:47 +00:00
|
|
|
_LOGGER.error("Error executing query: %s", err)
|
2017-02-26 22:38:06 +00:00
|
|
|
|
|
|
|
if tryno == RETRIES - 1:
|
|
|
|
raise
|
2019-02-27 21:10:40 +00:00
|
|
|
time.sleep(QUERY_RETRY_WAIT)
|
2020-07-18 05:07:37 +00:00
|
|
|
|
2021-07-13 19:21:45 +00:00
|
|
|
return None
|
|
|
|
|
2020-07-18 05:07:37 +00:00
|
|
|
|
2021-04-12 06:43:54 +00:00
|
|
|
def validate_or_move_away_sqlite_database(dburl: str) -> bool:
|
2020-07-18 05:07:37 +00:00
|
|
|
"""Ensure that the database is valid or move it away."""
|
2021-02-20 07:26:24 +00:00
|
|
|
dbpath = dburl_to_path(dburl)
|
2020-07-18 05:07:37 +00:00
|
|
|
|
|
|
|
if not os.path.exists(dbpath):
|
|
|
|
# Database does not exist yet, this is OK
|
|
|
|
return True
|
|
|
|
|
2021-04-12 06:43:54 +00:00
|
|
|
if not validate_sqlite_database(dbpath):
|
2021-02-20 07:26:24 +00:00
|
|
|
move_away_broken_database(dbpath)
|
2020-07-18 05:07:37 +00:00
|
|
|
return False
|
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
2021-02-20 07:26:24 +00:00
|
|
|
def dburl_to_path(dburl):
|
|
|
|
"""Convert the db url into a filesystem path."""
|
|
|
|
return dburl[len(SQLITE_URL_PREFIX) :]
|
|
|
|
|
|
|
|
|
2020-08-21 12:20:46 +00:00
|
|
|
def last_run_was_recently_clean(cursor):
|
|
|
|
"""Verify the last recorder run was recently clean."""
|
|
|
|
|
|
|
|
cursor.execute("SELECT end FROM recorder_runs ORDER BY start DESC LIMIT 1;")
|
|
|
|
end_time = cursor.fetchone()
|
|
|
|
|
|
|
|
if not end_time or not end_time[0]:
|
|
|
|
return False
|
|
|
|
|
|
|
|
last_run_end_time = process_timestamp(dt_util.parse_datetime(end_time[0]))
|
|
|
|
now = dt_util.utcnow()
|
|
|
|
|
|
|
|
_LOGGER.debug("The last run ended at: %s (now: %s)", last_run_end_time, now)
|
|
|
|
|
|
|
|
if last_run_end_time + MAX_RESTART_TIME < now:
|
|
|
|
return False
|
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
|
|
def basic_sanity_check(cursor):
|
|
|
|
"""Check tables to make sure select does not fail."""
|
|
|
|
|
|
|
|
for table in ALL_TABLES:
|
2021-06-30 11:32:17 +00:00
|
|
|
if table in [TABLE_STATISTICS, TABLE_STATISTICS_META]:
|
2021-05-16 17:23:37 +00:00
|
|
|
continue
|
2021-04-12 06:43:54 +00:00
|
|
|
if table in (TABLE_RECORDER_RUNS, TABLE_SCHEMA_CHANGES):
|
|
|
|
cursor.execute(f"SELECT * FROM {table};") # nosec # not injection
|
|
|
|
else:
|
|
|
|
cursor.execute(f"SELECT * FROM {table} LIMIT 1;") # nosec # not injection
|
2020-08-21 12:20:46 +00:00
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
2021-04-12 06:43:54 +00:00
|
|
|
def validate_sqlite_database(dbpath: str) -> bool:
|
2020-07-18 05:07:37 +00:00
|
|
|
"""Run a quick check on an sqlite database to see if it is corrupt."""
|
|
|
|
import sqlite3 # pylint: disable=import-outside-toplevel
|
|
|
|
|
|
|
|
try:
|
|
|
|
conn = sqlite3.connect(dbpath)
|
2021-04-12 06:43:54 +00:00
|
|
|
run_checks_on_open_db(dbpath, conn.cursor())
|
2020-07-18 05:07:37 +00:00
|
|
|
conn.close()
|
|
|
|
except sqlite3.DatabaseError:
|
2021-03-19 14:26:36 +00:00
|
|
|
_LOGGER.exception("The database at %s is corrupt or malformed", dbpath)
|
2020-07-18 05:07:37 +00:00
|
|
|
return False
|
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
2021-04-12 06:43:54 +00:00
|
|
|
def run_checks_on_open_db(dbpath, cursor):
|
2020-08-21 12:20:46 +00:00
|
|
|
"""Run checks that will generate a sqlite3 exception if there is corruption."""
|
2021-02-20 06:18:21 +00:00
|
|
|
sanity_check_passed = basic_sanity_check(cursor)
|
|
|
|
last_run_was_clean = last_run_was_recently_clean(cursor)
|
|
|
|
|
|
|
|
if sanity_check_passed and last_run_was_clean:
|
2020-08-21 12:20:46 +00:00
|
|
|
_LOGGER.debug(
|
2021-04-12 06:43:54 +00:00
|
|
|
"The system was restarted cleanly and passed the basic sanity check"
|
2020-09-02 08:12:56 +00:00
|
|
|
)
|
|
|
|
return
|
|
|
|
|
2021-02-20 06:18:21 +00:00
|
|
|
if not sanity_check_passed:
|
|
|
|
_LOGGER.warning(
|
|
|
|
"The database sanity check failed to validate the sqlite3 database at %s",
|
|
|
|
dbpath,
|
|
|
|
)
|
|
|
|
|
|
|
|
if not last_run_was_clean:
|
|
|
|
_LOGGER.warning(
|
2021-03-19 14:26:36 +00:00
|
|
|
"The system could not validate that the sqlite3 database at %s was shutdown cleanly",
|
2021-02-20 06:18:21 +00:00
|
|
|
dbpath,
|
|
|
|
)
|
|
|
|
|
2020-08-21 12:20:46 +00:00
|
|
|
|
2021-02-20 07:26:24 +00:00
|
|
|
def move_away_broken_database(dbfile: str) -> None:
|
2020-07-18 05:07:37 +00:00
|
|
|
"""Move away a broken sqlite3 database."""
|
|
|
|
|
|
|
|
isotime = dt_util.utcnow().isoformat()
|
|
|
|
corrupt_postfix = f".corrupt.{isotime}"
|
|
|
|
|
|
|
|
_LOGGER.error(
|
|
|
|
"The system will rename the corrupt database file %s to %s in order to allow startup to proceed",
|
|
|
|
dbfile,
|
|
|
|
f"{dbfile}{corrupt_postfix}",
|
|
|
|
)
|
|
|
|
|
|
|
|
for postfix in SQLITE3_POSTFIXES:
|
|
|
|
path = f"{dbfile}{postfix}"
|
|
|
|
if not os.path.exists(path):
|
|
|
|
continue
|
|
|
|
os.rename(path, f"{path}{corrupt_postfix}")
|
2021-04-19 15:22:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
def execute_on_connection(dbapi_connection, statement):
|
|
|
|
"""Execute a single statement with a dbapi connection."""
|
|
|
|
cursor = dbapi_connection.cursor()
|
|
|
|
cursor.execute(statement)
|
|
|
|
cursor.close()
|
|
|
|
|
|
|
|
|
2021-05-17 17:42:12 +00:00
|
|
|
def setup_connection_for_dialect(dialect_name, dbapi_connection, first_connection):
|
2021-04-19 15:22:38 +00:00
|
|
|
"""Execute statements needed for dialect connection."""
|
|
|
|
# Returns False if the the connection needs to be setup
|
|
|
|
# on the next connection, returns True if the connection
|
|
|
|
# never needs to be setup again.
|
|
|
|
if dialect_name == "sqlite":
|
2021-05-17 17:42:12 +00:00
|
|
|
if first_connection:
|
|
|
|
old_isolation = dbapi_connection.isolation_level
|
|
|
|
dbapi_connection.isolation_level = None
|
|
|
|
execute_on_connection(dbapi_connection, "PRAGMA journal_mode=WAL")
|
|
|
|
dbapi_connection.isolation_level = old_isolation
|
|
|
|
# WAL mode only needs to be setup once
|
|
|
|
# instead of every time we open the sqlite connection
|
|
|
|
# as its persistent and isn't free to call every time.
|
|
|
|
|
|
|
|
# approximately 8MiB of memory
|
|
|
|
execute_on_connection(dbapi_connection, "PRAGMA cache_size = -8192")
|
2021-04-19 15:22:38 +00:00
|
|
|
|
|
|
|
if dialect_name == "mysql":
|
|
|
|
execute_on_connection(dbapi_connection, "SET session wait_timeout=28800")
|
|
|
|
|
|
|
|
|
|
|
|
def end_incomplete_runs(session, start_time):
|
|
|
|
"""End any incomplete recorder runs."""
|
|
|
|
for run in session.query(RecorderRuns).filter_by(end=None):
|
|
|
|
run.closed_incorrect = True
|
|
|
|
run.end = start_time
|
|
|
|
_LOGGER.warning(
|
|
|
|
"Ended unfinished session (id=%s from %s)", run.run_id, run.start
|
|
|
|
)
|
|
|
|
session.add(run)
|
2021-05-16 17:23:37 +00:00
|
|
|
|
|
|
|
|
2021-07-13 19:21:45 +00:00
|
|
|
def retryable_database_job(description: str) -> Callable:
|
2021-05-16 17:23:37 +00:00
|
|
|
"""Try to execute a database job.
|
|
|
|
|
|
|
|
The job should return True if it finished, and False if it needs to be rescheduled.
|
|
|
|
"""
|
|
|
|
|
2021-07-13 19:21:45 +00:00
|
|
|
def decorator(job: Callable) -> Callable:
|
2021-05-16 17:23:37 +00:00
|
|
|
@functools.wraps(job)
|
|
|
|
def wrapper(instance: Recorder, *args, **kwargs):
|
|
|
|
try:
|
|
|
|
return job(instance, *args, **kwargs)
|
|
|
|
except OperationalError as err:
|
|
|
|
if (
|
|
|
|
instance.engine.dialect.name == "mysql"
|
|
|
|
and err.orig.args[0] in RETRYABLE_MYSQL_ERRORS
|
|
|
|
):
|
|
|
|
_LOGGER.info(
|
|
|
|
"%s; %s not completed, retrying", err.orig.args[1], description
|
|
|
|
)
|
|
|
|
time.sleep(instance.db_retry_wait)
|
|
|
|
# Failed with retryable error
|
|
|
|
return False
|
|
|
|
|
|
|
|
_LOGGER.warning("Error executing %s: %s", description, err)
|
|
|
|
|
|
|
|
# Failed with permanent error
|
|
|
|
return True
|
|
|
|
|
|
|
|
return wrapper
|
|
|
|
|
|
|
|
return decorator
|
2021-05-17 21:27:51 +00:00
|
|
|
|
|
|
|
|
|
|
|
def perodic_db_cleanups(instance: Recorder):
|
|
|
|
"""Run any database cleanups that need to happen perodiclly.
|
|
|
|
|
|
|
|
These cleanups will happen nightly or after any purge.
|
|
|
|
"""
|
|
|
|
|
|
|
|
if instance.engine.dialect.name == "sqlite":
|
|
|
|
# Execute sqlite to create a wal checkpoint and free up disk space
|
|
|
|
_LOGGER.debug("WAL checkpoint")
|
|
|
|
instance.engine.execute("PRAGMA wal_checkpoint(TRUNCATE);")
|