MariaDB

Overview

Signals reads conversion and customer data straight from a MariaDB database on a schedule and sends the columns you nominate to your ad platforms.

Reading it directly means there is no file job to maintain and nothing to go stale between runs. Signals reads only; nothing is written back.

You can point it at a table, or at a query. The query path is what you want when the shape Signals needs does not match anything you already have.

MariaDB began in 2009 as a fork of MySQL 5.1 and tracked MySQL’s numbering as far as 5.5, then went its own way at MariaDB 10.0, so 10.x and 11.x correspond to no particular MySQL version. A release number therefore proves nothing about which features are present: a data type, a status variable or an authentication method documented on the MySQL side may be missing here, may carry a different name, or may exist with different semantics. Establish which release the server runs and check the MariaDB documentation for it, rather than reasoning across from MySQL and finding out at connection time.

Supported destinations

Destinations supported by MariaDB

Category	Supported
Offline Conversions	Google Offline Conversions API Google Store Sales LinkedIn Offline Conversions API Meta Offline Conversions API OpenAI Offline Conversions API Snapchat Offline Conversions API TikTok Offline Events API
Lead Conversions	Google Enhanced Conversions for Leads LinkedIn Leads Conversions API Meta Conversions API for CRM Snapchat Leads Conversions API TikTok CRM Integrations
Custom Audience	Google Customer Match Meta Custom Audience Snapchat Custom Audience TikTok Custom Audience

Authentication

In Studio, open Sources, find the Database category, and click the MariaDB tile.

Field	What it is	Where to find it
Authentication Name	Your own label for this set of credentials.	You choose it. Name it for the database it belongs to.
Username	The database user Signals connects as.	Created in the database by your administrator.
Password	The password for that user.	Set when the user was created.

Caution

Create a dedicated read-only user for Datahash rather than reusing an application or administrator account. It keeps the connection working when someone rotates a password, and it stops the connection seeing more than it needs. Enter the password on the Datahash connection screen only.

Read privilege over one named database, and nothing beyond it, is the whole of what this account needs:

CREATE USER 'datahash'@'%' IDENTIFIED BY '...';
GRANT SELECT ON appdb.* TO 'datahash'@'%';

Spell out the database. Substituting a wildcard for appdb is the shortcut that gets taken under time pressure, and it leaves an account able to read internal catalogs and every unrelated application schema on the same server, forever, because nobody revisits a privilege that is not causing errors.

MariaDB provides an ed25519 authentication plugin that has no counterpart on the MySQL side, so an account hardened with it is unusable from any client implementing only the MySQL plugin set. Where a security baseline picks the plugin for every new account, find out which one this account got before anyone starts changing the password.

Configuration

Instance Setup

Select the Integration Type, which is the kind of data your records hold. Offline Events is the common choice. Give the instance a name, then choose the table path or the query path. On either path you enter the Database Name, Host Name and Port, and then either the Table Name or a SQL query.

The integration type decides the columns Signals expects and which destinations the connection can feed, so it is worth settling before anyone models the data. It also decides which file format you get on the next screen.

Which endpoint to enter

3306 is where a stock server listens. A cluster fronted by MaxScale is the case that catches people, because the proxy has its own listeners: 4006 is the conventional port for a read-write split listener, and the ports for other listener types are whatever the MaxScale configuration assigns. Typing the address of a backend server gives you a connection that works today while quietly bypassing the routing the cluster was built to perform, and the cost surfaces later as read traffic on a node nobody intended to serve it.

Every member of a Galera cluster serves reads, so any member is a valid host to enter, and that is exactly why the choice needs a moment’s thought: a connection pinned to one member is only as available as that member. An address that fronts the cluster, whether a proxy or a load balancer, survives the loss of a node; a bare node address does not.

Table path

Enter the connection details including the table name, then complete the setup. The name is typed rather than picked from a list, so it has to match the database exactly.

Query path

Enter the connection details without the table name, then write the query. Preview the results before finishing, and read the column names in the output rather than just the row count: a query that runs but returns the wrong names will fail silently once the connection is live.

Manage instance

One instance reads one table or query for one integration type. To read another, add another instance from the Manage existing instance table. To change an existing one, open it from there, click the edit option in the menu to the top right, update the fields and click Finish.

File format and schema

Download the file format from the setup screen and shape the table to it. The column names are what Signals matches on, so a column that has been renamed or cased differently is not recognized and the row it belongs to is dropped rather than reported.

On the query path the same rule applies to the column aliases your query returns. Aliasing to the expected names is the usual way to reconcile data you cannot or should not restructure.

Data & identifiers

Personal identifiers are normalized and hashed before they are sent to a destination.

Best practices

• Use a dedicated read-only user scoped to the data Datahash reads, rather than an application account.
• Prefer the query path with explicit column aliases over pointing at a raw table. It lets your team change the underlying model without breaking the connection.
• Point the read at InnoDB tables where the choice exists. Aria is not transactional, so it does not carry InnoDB’s recovery guarantees after an unclean shutdown, and it locks at table level where InnoDB locks at row level, which means a long scheduled read holds up writers that InnoDB would have let through.
• Clean the data in the view or query: lowercase email, phone in E.164, no stray whitespace. Hashing a badly formatted value produces a hash that will never match.
• Rotate the password periodically and update the connection afterwards.

Troubleshooting & FAQ

The connection times out rather than reporting bad credentials. That points at reachability rather than authentication. Confirm the host is exposed, the port is open, and any firewall or allow list permits the connection.

Credentials are rejected. Check the user can read the data from a client of its own first. Most failures here are permissions rather than typos.

The table name is rejected. It is typed rather than selected, so it has to match exactly.

A host that is plainly running turns queries away with a node-state error. A Galera member that has not finished joining the cluster refuses queries with ERROR 1047, WSREP has not yet prepared node for application use, rather than serving rows it cannot vouch for. wsrep_local_state_comment on that member says where it is in the process. Not every non-Synced state does this: a member reading Donor/Desynced keeps answering queries by default, which is what makes it usable as a backup source. Where the refusal is what you are seeing, either wait for the join to complete or find out why the member left. Addressing the cluster through a proxy that health-checks cluster state, MaxScale’s galeramon monitor for instance, keeps the failure off the connection; a plain TCP load balancer cannot tell the difference and keeps routing to the member.

The failure names a plugin it cannot load. The account was created with an authentication method the connecting client does not implement, ed25519 being the usual one on MariaDB, and the error text points at the method rather than at the credentials. Either connect with a client built against MariaDB, or move the account onto the native method with ALTER USER 'datahash'@'%' IDENTIFIED VIA mysql_native_password USING PASSWORD('...'). Alter the account rather than dropping and recreating it: a fresh account arrives with none of the read privilege set up earlier, so the authentication error becomes a permissions error. The password is not the problem and changing it will not help.

The query previews correctly but nothing is delivered. The column names it returns do not match the expected schema. Alias them to the names in the downloaded file format.

It was working and stopped. The password may have been changed or the user disabled. A dedicated service user avoids this.