AzureFile volume mount for mysql container

[50c]

Please provide us with the following information:

This issue is a: (mark with an x)

• [x ] bug report -> please search issues before submitting
• [ ] documentation issue or request
• [ ] regression (a behavior that used to work and stopped in a new release)

Issue description

I have issue to deploy a container with mysql server instance and using AzureFile volume mount for it's persistent data. I'm using terraform for deployment, so may be something is wrong with this part, but I don't see anything suspect there.

Steps to reproduce

1. My terraform deployment contains following parts:

resource "azurerm_storage_account" "mysql_storage" {
  name                     = "mysqlstorage${random_string.name.result}"
  resource_group_name      = var.resource_group_name
  location                 = var.resource_location
  account_tier             = "Premium"
  account_replication_type = "LRS"
  account_kind             = "FileStorage"
  tags = var.tags_extra
}

resource "azurerm_storage_share" "mysql_storage_data_share" {
  name                 = "mysql-storage-data-share"
  storage_account_name = azurerm_storage_account.mysql_storage.name
  quota                = 100
  enabled_protocol = local.storage_protocol
  depends_on = [ azurerm_storage_account.mysql_storage ]
}

resource "azurerm_container_app_environment_storage" "mysql_datashare" {
  name                         = "mda-mysql-env-data-storage"
  container_app_environment_id = var.container_app_environment_id
  account_name                 = azurerm_storage_account.mysql_storage.name
  share_name                   = azurerm_storage_share.mysql_storage_data_share.name
  access_key                   = azurerm_storage_account.mysql_storage.primary_access_key
  access_mode                  = "ReadWrite"
}

resource "azurerm_container_app" "mysql" {
  name = local.mysql_container_name

  container_app_environment_id = var.container_app_environment_id
  resource_group_name          = var.resource_group_name
  revision_mode                = "Single"
  depends_on                   = [azurerm_storage_account.mysql_storage, azurerm_storage_share.mysql_storage_data_share, azurerm_container_app_environment_storage.mysql_datashare]
  tags                         = var.tags_extra

  ingress {
    allow_insecure_connections = false
    external_enabled           = false
    transport                  = "tcp"
    target_port                = 3306
    exposed_port               = 3306
    traffic_weight {
      percentage      = 100
      latest_revision = true
    }

  }
  template {

    volume {
      storage_name = azurerm_container_app_environment_storage.mysql_datashare.name
      storage_type = "AzureFile"
      name         = "data"
    }
    container {
      name   = "mysql"
      image  = "mysql:8.3.0"
      cpu    = 2
      memory = "4Gi"
      volume_mounts {
        name = "data"
        path = "/var/lib/mysql"
      }
      dynamic "env" {
        for_each = local.env
        content {
          name  = env.key
          value = env.value
        }
      }
    }
    min_replicas = 1
    max_replicas = 1
  }
}

2. terraform apply

3. check azure logs

Expected behavior [What you expected to happen.] Db instance is starting properly

Actual behavior [What actually happened.] Instance not started, logs from analytics:

"2024-04-04T10:12:53.211179Z 0 [System] [MY-015015] [Server] MySQL Server - start." "'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'" "2024-04-04 10:12:52+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.3.0-1.el8 started." "2024-04-04 10:12:52+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'" "2024-04-04 10:12:52+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.3.0-1.el8 started." "2024-04-04T10:07:50.131976Z 0 [System] [MY-015016] [Server] MySQL Server - end." "2024-04-04T10:07:50.131961Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.3.0) MySQL Community Server - GPL." "2024-04-04T10:07:50.130667Z 0 [ERROR] [MY-010119] [Server] Aborting" "2024-04-04T10:07:50.130631Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed." "2024-04-04T10:07:50.130447Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine" "2024-04-04T10:07:49.835846Z 1 [ERROR] [MY-012930] [InnoDB] Plugin initialization aborted with error Generic error." "2024-04-04T10:07:49.835758Z 1 [ERROR] [MY-012960] [InnoDB] Cannot create redo log files because data files are corrupt or the database was not shut down cleanly after creating the data files." "2024-04-04T10:07:49.513979Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started." "2024-04-04T10:07:49.491404Z 0 [Warning] [MY-010075] [Server] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 3123c186-f26b-11ee-b647-960f4218ec2f." "2024-04-04T10:07:49.489360Z 0 [Warning] [MY-010107] [Server] World-writable config file '/var/lib/mysql/auto.cnf' has been removed." "2024-04-04T10:07:49.482780Z 0 [Warning] [MY-000054] [Server] World-writable config file '/var/lib/mysql/auto.cnf' is ignored." "2024-04-04T10:07:49.408505Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.3.0) starting as process 1" "2024-04-04T10:07:49.201109Z 0 [System] [MY-015015] [Server] MySQL Server - start." ...

Screenshots
Fileshare has a bunch of created mysql files. I don't see a problem with it:

Additional context

I'l be very happy if someone can point me into the right direction. I'm struggleing several days with the problem Thank you

[antidoid]

Can confirm I'm facing the same issue. Were you able to solve it?

[50c]

Can confirm I'm facing the same issue. Were you able to solve it?

Sadly no, I have stuck using other database. But I would be interested if there is a solution for this, not really unusual deployment challenge exist

[antidoid]

Yeah, I ended up using mariadb.

[RadoslavGatev]

I faced the same issue. Moved to mariadb.

[DavidMarquezF]

I managed to half-solve it by using the MountOptions available in the Volume tab when creating a revision.

dir_mode=0777,file_mode=0777,uid=999,gid=999,nobrl,mfsymlinks,cache=none

It can start and it works properly (i can use mysql). The problem is that when the container is restarted (so two containers try to access the same volume) it consistently cannot start. It seems like using DB with Azure file shares is not really optimal; not only from a performance point of view, but because all the file permission configurations are lost