Azure CLI is really handy for all sorts of tasks. When I build solutions, POCs and environments and I want to tear down the resources I like to use Azure CLI over the Portal. Below will show you the commands I use.
I mentioned before that you could use the idea of data persistency to rebuild your data from total failure. There are two types. RDB and AOF.
RDB – persists a snapshot of your cache in a binary format. The snapshot is saved in an Azure Storage account. AOF – saves every write operation to a log. The log is saved at least once per second into an Azure Storage account.
This is quite an in-depth topic area and I suggest further reading to determine which one suits you: https://redis.io/topics/persistence#aof-disadvantages
To set this up you will see data persistence section within your Redis Cache
Lets summarise some important learnings about SQL MI and failover groups.
Following on from my last post after creating AKS, I now want to work with SQL server. First step, load up Azure cloud shell.
It has been a while since I wrote a blog post for TSQL Tuesday and there is no better time then now following on from Brent Ozar’s Invite about our favourite data types in SQL server.
Following on from a previous blog post (https://blobeater.blog/2021/01/15/sql-server-linux/) on installing SQL Linux, a common requirement will be the need to connect to it to issue queries, typically via SQLCMD). There isn’t too much to it but still an important step.
If you have come from a windows background you may be curious about the world of SQL Server Linux. Yes, the operating system and the implementation of it differs to the traditional Windows environment but once installed, it’s just good old SQL server and those lovely DBCC commands and backup statements work, all your DMVs are ready for you too.
Being in the cloud does have many benefits, from lower administration to fast scaling but another “side effect” of operating in Azure SQL Database is the cloud first nature of changes. By this I basically mean new features always get pushed to Azure first before the classic on-premises version so some gems come to light.
Quick video showing you how to failover your Azure SQL Database between your primary and secondary location.
Since SQL Server 2016 we could leverage Microsoft Azure to dynamically move “cold” portions of data away from on-premises storage for longer retention time periods. Whilst in theory being a great idea the cost was a blocker for some and with a cumbersome setup process. SQL Server 2019 addresses this by making the costs of storing the data in the cloud more competitive and making the setup more streamlined with the use of the Data Migration Assistant (DMA) tool and SSMS (SQL Server Management Studio).
Note: DMA tool replaces the older Upgrade Advisor tool. To install DMA please see the following link https://docs.microsoft.com/en-us/sql/dma/dma-overview?view=sql-server-ver15.
All About Data 