Периодически перестают записываться данные в materilized view Azure Cosmos DB Cassandra api

Question

Периодически перестают записываться данные в materilized view Azure Cosmos DB Cassandra api. То работает, то перестают реплицироваться.

Answer 1

Привет,

Проблема была изначально или она появилась в последсвии? Если проблема изначально была, то скорее всего есть проблема в конфигурации, если она появилась потом, то посмотрите журналы операций (operation logs) и диагностические логи (diagnostic logs) в портале Azure для поиска ошибок и предупреждений, связанных с репликацией данных в materialized view.

Дополнительно высокая нагрузка на базу данных может тоже вызвать проблемы с репликацией. Проверьте метрики производительности и использование ресурсов в Azure Portal. Рассмотрите и возможность масштабирования вашей базы данных, увеличив количество RU (Request Units), чтобы справляться с увеличенной нагрузкой.

Также ознакомьтесь с лимитациями materialized view, возможно причина в них:

Current limitations

There are a few limitations with the API for Cassandra's preview implementation of materialized views:

• Materialized views can't be created on a table that existed before support for materialized views was enabled on the account. To use materialized views, create a new table after the feature is enabled.
• For the materialized view definition’s WHERE clause, only IS NOT NULL filters are currently allowed.
• After a materialized view is created against a base table, ALTER TABLE ADD operations aren't allowed on the base table’s schema. ALTER TABLE APP is allowed only if none of the materialized views have selected * in their definition.
• There are limits on partition key size (2 Kb) and total length of clustering key size (1 Kb). If this size limit is exceeded, the responsible message will end up in poison message queue.
• If a base table has user-defined types (UDTs) and materialized view definition has either SELECT * FROM or has the UDT in one of projected columns, UDT updates aren't permitted on the account.
• Materialized views may become inconsistent with the base table for a few rows after automatic regional failover. To avoid this inconsistency, rebuild the materialized view after the failover.
• Creating materialized view builder instances with 32 cores isn't supported. If needed, you can create multiple builder instances with a smaller number of cores.

In addition to the above limitations, consider the following extra limitations:

• Availability zones
  • Materialized views can't be enabled on an account that has availability zone enabled regions.
    • Adding a new region with an availability zone isn't supported once enableMaterializedViews is set to true on the account.
• Periodic backup and restore
  • Materialized views aren't automatically restored with the restore process. You'll need to re-create the materialized views after the restore process is complete. Then, you should configure enableMaterializedViews on their restored account before creating the materialized views and builders again.
• Apache Cassandra
• Defining conflict resolution policy on materialized views isn't allowed.
• Write operations aren't allowed on materialized views.
• Cross document queries and use of aggregate functions aren't supported on materialized views.
• A materialized view's schema can't be modified after creation.
• Deleting the base table isn't allowed if at least one materialized view is defined on it. All the views must first be deleted and then the base table can be deleted.
  • Defining materialized views on containers with static columns isn't allowed. Current limitations There are a few limitations with the API for Cassandra's preview implementation of materialized views:
    • Materialized views can't be created on a table that existed before support for materialized views was enabled on the account. To use materialized views, create a new table after the feature is enabled.
    • For the materialized view definition’s WHERE clause, only IS NOT NULL filters are currently allowed.
    • After a materialized view is created against a base table, ALTER TABLE ADD operations aren't allowed on the base table’s schema. ALTER TABLE APP is allowed only if none of the materialized views have selected * in their definition.
    • There are limits on partition key size (2 Kb) and total length of clustering key size (1 Kb). If this size limit is exceeded, the responsible message will end up in poison message queue.
    • If a base table has user-defined types (UDTs) and materialized view definition has either SELECT * FROM or has the UDT in one of projected columns, UDT updates aren't permitted on the account.
  • Materialized views may become inconsistent with the base table for a few rows after automatic regional failover. To avoid this inconsistency, rebuild the materialized view after the failover.
  • Creating materialized view builder instances with 32 cores isn't supported. If needed, you can create multiple builder instances with a smaller number of cores.
  In addition to the above limitations, consider the following extra limitations:
  • Availability zones
    • Materialized views can't be enabled on an account that has availability zone enabled regions.
      • Adding a new region with an availability zone isn't supported once enableMaterializedViews is set to true on the account.
      • Periodic backup and restore
        • Materialized views aren't automatically restored with the restore process. You'll need to re-create the materialized views after the restore process is complete. Then, you should configure enableMaterializedViews on their restored account before creating the materialized views and builders again.
• Apache Cassandra
• Defining conflict resolution policy on materialized views isn't allowed.
• Write operations aren't allowed on materialized views.
• Cross document queries and use of aggregate functions aren't supported on materialized views.
• A materialized view's schema can't be modified after creation.
• Deleting the base table isn't allowed if at least one materialized view is defined on it. All the views must first be deleted and then the base table can be deleted.
  • Defining materialized views on containers with static columns isn't allowed.

Если ответ Вам помог, пожалуйста помечайте его как "Ответ". Заранее спасибо!