Adding initial version of Sky Docs

.github/workflows/ci.yml

@@ -0,0 +1,24 @@
+name: ci 
+on:
+  push:
+    branches:
+      - master 
+      - main
+permissions:
+  contents: write
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-python@v4
+        with:
+          python-version: 3.x
+      - uses: actions/cache@v2
+        with:
+          key: ${{ github.ref }}
+          path: .cache
+      - run: pip install mkdocs-material
+      - run: pip install pillow cairosvg
+      - run: pip install mkdocs-glightbox
+      - run: mkdocs gh-deploy --force

docs/Autonomously scale Compute, Storage afeeaa6466614d8d905efa44201746b2/README.md

@@ -0,0 +1,73 @@
+# Autonomously scale Compute, Storage
+
+Autonomous features enable automatic scaling in response to changes in workload.
+
+Auto-scale of nodes enables scaling based on load:
+
+- In/Out auto-scaling performs horizontal scaling, decreasing (In) or increasing (Out) the node count.
+- Up/Down auto-scaling performs vertical scaling, increasing (Up) or decreasing (Down) the instance size.
+
+Auto-scale of storage enables expansion of capacity based on usage.
+
+Autonomous features can be enabled at time of [service launch](https://mariadb.com/docs/skysql-dbaas/service-management/nr-launch/). Autonomous features can be enabled or disabled after launch.
+
+![https://mariadb.com/docs/_images/screenshots/services-tx-xpand-autonomous-dialog.png](https://mariadb.com/docs/_images/screenshots/services-tx-xpand-autonomous-dialog.png)
+
+
+
+## **Enable Auto-Scaling of Nodes**
+
+Auto-scaling of nodes can be enabled either at time of service launch or after service launch.
+
+During [service launch](https://mariadb.com/docs/skysql-dbaas/service-management/nr-launch/):
+
+- Check the "Enable auto-scale nodes" checkbox and set the desired scaling parameters.
+
+After service launch, [manage Autonomous settings](https://mariadb.com/docs/skysql-dbaas/service-management/nr-autonomous/#Manage_Autonomous_Settings), and enable the desired auto-scaling features.
+
+## **Enable Auto-Scaling of Storage**
+
+Auto-scaling of storage can be enabled either at time of service launch or after service launch.
+
+During [Service Launch](https://mariadb.com/docs/skysql-dbaas/service-management/nr-launch/):
+
+- Check the "Enable auto-scale storage" checkbox and set the desired maximum transactional data storage.
+
+After service launch, [manage Autonomous settings](https://mariadb.com/docs/skysql-dbaas/service-management/nr-autonomous/#Manage_Autonomous_Settings), and enable the desired auto-scaling features.
+
+For ColumnStore Data Warehouse, object storage adjusts automatically. Autonomous scaling features for storage are not used by this topology.
+
+## **Manage Autonomous Settings**
+
+To manage Autonomous settings:
+
+- From the [Portal](https://mariadb.com/docs/skysql-dbaas/working/nr-portal/), click the "MANAGE" button for the desired service, then choose "Autonomous" from the menu.
+- Update settings as desired.
+- Click "Apply Changes" when complete.
+
+## **Scaling Rules**
+
+Automatic scaling occurs based on rules.
+
+| Policy | Condition | Action |
+| --- | --- | --- |
+| Auto-Scale Disk | • Disk utilization > 90% sustained for 5 minutes
+The disk is expected to run out of capacity in the next 24 hours (predicted based on the last 6 hours of service usage) | • Upgrade storage to the next available size in 100GB increments
+• Note: you cannot downgrade storage, the upgrade is irreversible |
+| Auto-Scale Nodes Out | • CPU utilization > 75% over all replicas sustained for 30 minutes
+• Number of concurrent sessions > 90% over all replicas sustained for 1 hour
+• Number of concurrent sessions is expected to hit the maximum within 4 hours (predicted based on the last 2 hours of service usage) | • Add new replica or node
+• Additional nodes will be of the same size and configuration as existing nodes |
+| Auto-Scale Nodes In | • CPU utilization < 50% over all replicas sustained for 1 hour
+• Number of concurrent sessions < 50% over all replicas sustained for 1 hour | • Remove replica or node
+• Node count will not decrease below the initial count set at launch |
+| Auto-Scale Nodes Up | • Number of concurrent sessions is expected to hit the maximum within 4 hours (predicted based on the last 2 hours of service usage) | • Upgrade all nodes to the next available size |
+| Auto-Scale Nodes Down | • CPU utilization < 50% over all replicas sustained for 1 hour
+• Number of concurrent sessions < 50% over all replicas sustained for 1 hour | • Downgrade nodes
+• Node size will not decrease below the initial node size set at launch |
+
+Autonomous actions are not instantaneous.
+
+Cooldown periods may apply. A cooldown period is the time period after a scaling operation is completed before another scaling operation can occur. The cooldown period for storage scaling is 6 hours.
+
+[Uptime SLA](Uptime%20SLA%20ea985d9f82fc48b8bc0476cd359f48ce.md)

docs/Autonomously scale Compute, Storage afeeaa6466614d8d905efa44201746b2/Uptime SLA ea985d9f82fc48b8bc0476cd359f48ce.md

@@ -0,0 +1,104 @@
+# Uptime SLA
+
+MariaDB SkySQL customers should assess the availability requirements of their application and choose an appropriate service tier to meet their objectives. MariaDB SkySQL customers are on the Foundation Tier unless they have specifically purchased and paid for Power Tier service.
+
+## **Performance Standard**
+
+| Tier | Performance Standard |
+| --- | --- |
+| SkySQL Foundation Tier | • Multi-node configurations will deliver a 99.95% service availability on a per-billing-month basis.
+• For example, with this availability target in a 30 day calendar month the maximum service downtime is 21 minutes and 54 seconds. |
+| SkySQL Power Tier | • Multi-node configurations will deliver a 99.995% service availability on a per-billing-month basis.
+• For example, with this availability target in a 30 day calendar month the maximum service downtime is 2 minutes and 11 seconds. |
+
+## **Service Downtime**
+
+**Service Downtime** is measured at each SkySQL database endpoint as the total number of full minutes, outside of scheduled downtime for maintenance and upgrades, where continuous attempts to establish a connection within the minute fail as reflected in minute-by-minute logs.
+
+## **Monthly Uptime Percentage**
+
+**Monthly Uptime Percentage** is calculated on a per-billing-month basis as the total number of minutes in a month, minus the number of minutes of measured [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime) within the month, divided by the number of minutes in that month. When a service is deployed for only part of a month, it is assumed to be 100% available for the portion of the month that it is not deployed.
+
+## **Service Credit**
+
+**Service Credit** is the percentage of the total fees paid by you for a given SkySQL service during the month in which the downtime occurred to be credited if MariaDB approves your claim. The percentage used in calculating Service Credit is dependent on whether the customer is on Foundation Tier or Power Tier, and is dependent on the calculated [Monthly Uptime Percentage](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Monthly_Uptime_Percentage).
+
+| Tier | Monthly Uptime Percentage | Percentage Applied |
+| --- | --- | --- |
+| Foundation Tier | Less than 99.95%, but greater than or equal to 99.0% | 10% |
+| Foundation Tier | Less than 99.0% | 25% |
+| Power Tier | Less than 99.995%, but greater than or equal to 99.0% | 10% |
+| Power Tier | Less than 99.0% | 25% |
+
+MariaDB will grant and process claims, provided the customer has satisfied its [Customer Obligations](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Customer_Obligations) and that none of the [Exclusions](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Exclusions) listed apply to the claim. [Service Credits](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Credit) will be issued only upon request within 60 days of the end of the billing period of the month of impact to service availability, and upon confirmation of outage. [Service Credits](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Credit) will be issued in the form of a monetary credit applied to future use of the service that experienced the [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime). [Service Credits](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Credit) will not be applied to fees for any other SkySQL instance.
+
+The aggregate maximum number of [Service Credits](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Credit) to be issued by MariaDB to customers for any and all [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime) that occurs in a single billing month will not exceed 50% of the amount due from the customer for the covered service for the applicable month.
+
+## **Customer Obligations**
+
+A customer will forfeit their right to receive a [Service Credit](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Credit) unless they:
+
+- Log a support ticket with MariaDB Support within 60 minutes of first becoming aware of an event that impacts service availability.
+- Submit a claim and all required information by the end of the month immediately following the month when the [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime) occurred.
+- Submit necessary information for MariaDB to validate the claim, including:
+    - a description of the events resulting in the [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime), and related request logs
+    - the date, time, and duration of the [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime)
+    - the number and location(s) of affected users
+    - descriptions of customer attempts to fix the [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime) as it occurred
+- Provide reasonable assistance to MariaDB in investigating the cause of the [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime) and investigating your claim.
+
+## **Exclusions**
+
+- **Out-of-scope configurations**
+
+    The [Performance Standard](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Performance_Standard) does not apply to single instance SkySQL service configuration or services in Technical Preview. Customers requiring High Availability should deploy instead in production-ready multi-node service configuration.
+
+    See "[Choose a SkySQL Release](https://mariadb.com/docs/skysql-dbaas/working/nr-release-choice/)" for information on SkySQL services in Technical Preview.
+
+- **Underlying infrastructure**
+
+    Impact to service availability caused by availability or performance of cloud services used to operate MariaDB SkySQL is excluded. This includes any such outages in Amazon Web Services (AWS) and Amazon Elastic Kubernetes Service (EKS), and Google Cloud Platform (GCP) and Google Kubernetes Engine (GKE).
+
+- **Network interruption**
+
+    Impact to service availability caused by blocking of network traffic by ISPs, network providers, governments, or third parties is excluded.
+
+- **External factors**
+
+    Impact to your use of service based on factors outside MariaDB SkySQL are excluded. This includes periods of downtime for your applications.
+
+- **Uncorroborated impacts**
+
+    Only impacts to service availability detected at [point of measurement](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime) are subject when determining the uptime percentage. Service availability impacts measured through any other means, such as application instrumentation, are excluded except as also measured as [Service Downtime](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Service_Downtime) by MariaDB.
+
+- **Portal access**
+
+    Impact to your ability to access or use the MariaDB SkySQL portal, an interface provided to manage services, is excluded. This includes any component and content linked from the MariaDB SkySQL portal, including Documentation, the Customer Support portal, Monitoring, and Workload Analysis. These components operate independently from database services and do not impact database availability.
+
+- **Resource usage**
+
+    Impact to service availability caused by usage of system resources, such as problems caused by excessive workload consumption of CPU, disk I/O, disk capacity, memory, and other system resources, are excluded.
+
+- **Clients and connectors**
+
+    Impact to service availability caused by the use of unsupported third-party clients and connectors is excluded.
+
+- **Non-paying customers**
+
+    The [Performance Standard](https://mariadb.com/docs/skysql-dbaas/service-management/nr-sla/#Performance_Standard) applies only to paying MariaDB SkySQL customers who are paid-in-full. All other MariaDB SkySQL customers, including those not paid-in-full and those customers participating in a free or credited service trial, are excluded.
+
+- **Customer-directed maintenance**
+
+    When a customer directs that MariaDB conduct a maintenance operation on a service, any resulting impact to service availability is excluded.
+
+- **Customer-approved maintenance**
+
+    When a customer approves MariaDB-recommended maintenance on a service, any resulting impact to service availability is excluded.
+
+- **Customer-initiated changes**
+
+    When a customer initiates changes to their SkySQL services, e.g., via access to the database or via the SkySQL portal, any resulting impact to service availability is excluded.
+
+- **Initial provisioning**
+
+    Availability of services during initial provisioning, e.g., before a service becomes online, healthy, and available, is excluded.