Enterprise users who have a large number of MariaDB servers often want to centralize their MariaDB user account administration -- especially for the user accounts of the database administration team. This can simplify some database administration tasks, since users do not have to be manually created on every server.
Developing on your Mac? Get the latest stable MariaDB version set up on OS X easily with Homebrew. See this step by step guide on installing MariaDB 10.1.16.
Some of the most common questions asked by our users are regarding MariaDB support in Docker, and in particular how it can be used in specific development or production deployments. This series of articles will try to cover a few Docker and MariaDB use cases.
MariaDB works with many clients to migrate Microsoft SQL and Oracle to MariaDB. With the CONNECT storage engine we can access any ODBC data source in MariaDB. Here's a small HOWTO for those who want to give it a quick try. In this example we use MSSQL, though the same principle should be possible with Oracle ODBC servers.
The MaxScale persistent connection feature has been available since version 1.3.0. It aims to reduce the load on the database servers in specific scenarios. Testing indicates benefits and feedback from live use has been positive.
Several months ago, I wrote a blog post about configuring PAM authentication and user mapping in MariaDB. While it is useful to map a system user account to a MariaDB user account, a lot of users actually wanted to be able to map all system users in a particular system group to the same MariaDB user account without mapping the system accounts individually.
Losing temporary tables on a slave when
binlog_format is not set to
ROW is a well-known problem, and there is even a way to avoid it, as described by the safe slave shutdown procedure in the MySQL documentation. However, the documentation doesn't describe how to fix your slave if you accidentally shut it down while it has temporary tables open. In this blog post, I'll describe how to do that.
My last row-level security blog post got a few questions, so I decided that it would be good to follow up with more detail. The last blog post described some basic information about row-level security, but row-level security policies are highly dependent on an application's or organization's security requirements. In this blog post, I'm going to walk through an example row-level security implementation in MariaDB 10.0 in a little more detail.
Setting up data security correctly can be vital for systems at government agencies, e-commerce sites, hospitals and clinics, or any company with sensitive employee data. In this blog, Geoff shows you how to set up row-level security in MariaDB for use cases demanding more detailed privilege handling than MariaDB and MySQL provide out of the box.
User accounts in MariaDB have traditionally been completely separate from operating system accounts. However, MariaDB has included a PAM authentication plugin since version 5.2.10. With this plugin, DBAs can configure MariaDB user accounts to authenticate via PAM, allowing users to use their Linux username and password to log into the MariaDB server.