Is it possible to review the history of changes to the setting of an Azure Cosmos database. I believe I am colliding with another them who is using the same Cosmos database. I would like to review all the setting that have changed since the database was created. Is that possible?
You can audit control plane operations for any Cosmos DB resource once it has been created. However, the account must be configured such that all control plane operations are done against the Cosmos DB resource provider and not through one of the data plane SDKs. See the link for details on this.
However, ARM does not support providing information on when a resource was created. This is a limitation of ARM, not Cosmos DB.
If you just wanna watch who did operations on your cosmos database, I think 'Activity Log' tab could help you. It records some message like screenshot below.
But I found that I can't get the details of the operations such as changing RU. By the way, I didn't find any documents saying how to review operations in cosmosdb. Or maybe you can provide more details about what information you wanna get from cosmosdb?
Related
Please forgive me if I am asking this question incorrectly or in a wrong place.
I am trying to understand how to use the change feed for the Cosmos DB.
I do have a Cosmos DB Emulator (a version of a Cosmos DB that is running locally on my machine)
I was able to use and populate it successfully. However, unfortunately, I see no way to view or access the change feed.
Is this even possible to access the change feed on the Cosmos DB Emulator?
Thank you very much in advance
There is no UI for the Change Feed, since the Change Feed is a timeline that could be consuming from multiple points on different ways.
Consuming the Change Feed is always programmatic and done through any of the available methods.
in the project i am working on, we have a database per tenant and each tenant consists of at least 1 department. One of the requirements we have is that when an admin user deletes a department using a custom frontend we've provided, the system should first archive the data of that department on a blob storage before the data is deleted. The same we have for the tenant, we need to archive the data before the database of that tenant is removed from the account.
Now, my question: is there any best practice to do this? We are planning to retrieve all the data from all collections, using a mongo query, based on the department id (which is also the partition key) and then send it to a blob storage. The challenge we have is the execution of the query to retrieve all the data because it can be a huge amount and the RUs required for that action may affect the performance of the system because other users may be using the system while we remove the data.
I looked at mongodump and mongoexport but these are applications so we cannot execute it from our code?
Any ideas? Thanks a lot.
I think one way to solve this is by using ChangeFeed, as it reallyhelps and simplifies writing a carbon copy somewhere else.
However, as of now the change feed processor won't notify you for deleted documents so you can't listen for them, this feature is planned as of now.
Your best bet is to write some custom application that does archiving using Query language support
One colleague said that cosmos db will stop supporting collections without a partition key. But I can't find any information about this statement from Microsoft.
The application I'm working on has a collection of order records. A typical query returns 10s of thousands of these records. So if I use order id as partition key, it'll always run cross partition queries.... And the requirement is to get all records across all tenants, so partition by tenant id isn't an option, either.
I thought it'll be fine just create a collection without a partition key. I'll worry about archiving data later (probably with azure functions and change feed).
Is it a good idea to do so?
One colleague said that cosmos db will stop supporting collections
without a partition key. But I can't find any information about this
statement from Microsoft.
Based on the tips on the cosmos db portal,this message is confined to portal only so far.
You still could create non-partitioned collection by using sdk:
DocumentCollection collection = new DocumentCollection();
collection.set("id","jay");
ResourceResponse<DocumentCollection> createColl = client.createCollection("dbs/db",collection,null);
So,i think your service will not be affected by now. As for future trends, I suggest you pay more attention to Microsoft's official statement. If you have any special needs, you can submit feedback for help.
in my Azure Cosmos DB account, I can add multiple databases (containing multiple collections).
However, I only seem to find account-level connection strings (secrets), that are valid for each database. Differing only in the database name section.
I find this odd. Is this expected? If I want more granular control do I need to create separate accounts for each database?
PS: I'm using the Mongo API if it's somehow relevant.
Cheers
The account-level connection strings you mentioned in the question is master key.Based on this document, Azure Cosmos DB uses two types of keys to authenticate users and provide access to its data and resources.
Master keys cannot be used to provide granular access to containers and documents.
If you want more granular control,please get an idea of Resource Tokens which provides access to specific containers, partition keys, documents, attachments, stored procedures, triggers, and UDFs.More details,please refer to this link.
Is it possible to get the size of every partition in a Cosmos DB collection? I know the portal will show the top few partitions in a collection, in the Metrics blade, but I'm interesting in seeing the size of every partition.
I believe you should be able to get this data through the Cosmos DB REST API.
It doesn't seem to be exposed through the .NET SDK so you'd need to write some C# or PowerShell yourself to access the data however, it should be available.
Link is:
https://learn.microsoft.com/en-us/rest/api/cosmos-db-resource-provider/collectionpartition/listusages