Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23748

support not-MAC-address based UUID versions

Details

    Description

      So far as I know, this affects all versions of MariaDB.

      On Linux, FreeBSD, and (perhaps) MacOS, MariaDB uses the host MAC address as the basis for generating v1 UUID values in the UUID() function. On Windows, it generates a random nonce and uses that instead of a MAC address.

      In cloud or virtual machine deployments, it is likely that

      1. MAC addresses are not unique (e.g. all Hyper-V installations use the same small pool by default), or
      2. Multiple copies of MariaDB may end up running in adjacent containers that execute on the same underlying machine (and therefore share a MAC address).

      On Windows deployments this has not been an issue, because these deployments generate random nonces instead of using the MAC address.

      It would be helpful if it were possible to configure the Linux/FreeBSD/?Mac installations to use such a nonce in environments where the uniqueness of the MAC address is uncertain or unreliable. Since the nonce support code is already present, one might hope this would not be a big lift.

      Attachments

        Issue Links

          includes

          New Feature - A new feature of the product, which has yet to be developed. MDEV-11339 Support UUID v4 generation

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          New Feature - A new feature of the product, which has yet to be developed. MDEV-32637 Implement native UUID7 function

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          relates to

          Task - A task that needs to be done. MDEV-4958 Adding datatype UUID

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            wlad Vladislav Vaintroub added a comment -

            shap, "On Windows, it generates a random nonce and uses that instead of a MAC address."
            Really? Maybe I'm missing something , but my_gethwaddr is implemented there, which serves as uuid suffix.

            wlad Vladislav Vaintroub added a comment - shap , "On Windows, it generates a random nonce and uses that instead of a MAC address." Really? Maybe I'm missing something , but my_gethwaddr is implemented there, which serves as uuid suffix.
            serg Sergei Golubchik added a comment -

            v1 UUID must use the mac address.

            So this is, basically, a (valid) request to implement UUID version 3, 4, or 5.

            serg Sergei Golubchik added a comment - v1 UUID must use the mac address. So this is, basically, a (valid) request to implement UUID version 3, 4, or 5.
            tgross35 Trevor Gross added a comment -

            Keeping UUID() to be a UUIDv1 generator based on mac address seems necessary for MySQL compatibility.

            As a random user, I'd vouch for implementing UUID generation functions the way that the postgres plugin does it https://www.postgresql.org/docs/13/uuid-ossp.html

            • uuid_generate_v1() : UUIDv1 generator using real HW mac address (same as UUID() is currently for My/Maria)
            • uuid_generate_v1mc(): UUIDv1 but use a randomly generated mac. It makes sense to me that this random mac should be saved as a global variable, for consistency if the DB is restarted or moved (unsure how PG handles this).
            • uuid_generate_v3(namespace, name): UUIDv3, MD5 namespace
            • uuid_generate_v4(): UUIDv4, full random UUID
            • uuid_generate_v5(namespace, name): UUIDv5, SHA-1 namespace

            In my opinion, uuid_generate_v4 and uuid_generate_v1mc would be the most useful to have. The mc version with the mac saved to a variable would nicely address circumstances where generating node needs to be tracked (so v4 isn't usable), but tracked to the database instance rather than the server it runs on.

            tgross35 Trevor Gross added a comment - Keeping UUID() to be a UUIDv1 generator based on mac address seems necessary for MySQL compatibility. As a random user, I'd vouch for implementing UUID generation functions the way that the postgres plugin does it https://www.postgresql.org/docs/13/uuid-ossp.html uuid_generate_v1() : UUIDv1 generator using real HW mac address (same as UUID() is currently for My/Maria) uuid_generate_v1mc(): UUIDv1 but use a randomly generated mac. It makes sense to me that this random mac should be saved as a global variable, for consistency if the DB is restarted or moved (unsure how PG handles this). uuid_generate_v3(namespace, name): UUIDv3, MD5 namespace uuid_generate_v4(): UUIDv4, full random UUID uuid_generate_v5(namespace, name): UUIDv5, SHA-1 namespace In my opinion, uuid_generate_v4 and uuid_generate_v1mc would be the most useful to have. The mc version with the mac saved to a variable would nicely address circumstances where generating node needs to be tracked (so v4 isn't usable), but tracked to the database instance rather than the server it runs on.
            danblack Daniel Black added a comment -

            With both UUIDv4 and UUIDv7 I think we've covered this requirement.

            danblack Daniel Black added a comment - With both UUIDv4 and UUIDv7 I think we've covered this requirement.

            People

              Unassigned Unassigned
              shap Jonathan Shapiro
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.