I've seen that a lot. When I import Drupal databases, I learnt to use its Backup and Migrate module instead, it works flawlessly. Downside is you need to do clean Drupal installation first, but that basically is just creating blank database and putting brick on enter key.

@Obsolesce said in UREs Strike InnoDB on MySQL:

@scottalanmiller said in UREs Strike InnoDB on MySQL:

@Pete-S said in UREs Strike InnoDB on MySQL:

Step one is to remove the drives and clone them with dd or recovery tool to a new drive.
You could probably recover 99.9% of the data - if you want.

As you can guess from all of their previous issues, they don't want to pay for any recovery, they just want it magically fixed for free. They don't own any storage onto which to clone it, either.

Then what is the point of any of it? It appears to have zero value to the business.

I said that to them.

@scottalanmiller said in Bookstack Backup to S3:

@wrx7m said in Bookstack Backup to S3:

@dbeato said in Bookstack Backup to S3:

@wrx7m said in Bookstack Backup to S3:

@dbeato Are you running bookstack in AWS?

Not at the moment. I am just backing up to S3.

Look at Wasabi for S3 compatible object storage. Significantly cheaper.

Yup, can't think of any reason to use S3 unless you are hosted on AWS and aren't using it for backup but for production storage. And even then, not the majority of the time. S3 is too expensive and doesn't really offer anything except locality that is of any specific value. B2 and Wasabi beat it a lot.

Sorry, I posted this as S3 but I should change it to Wasabi. It is the same Idea for both.

@DustinB3403 said in MySQL MariaDB password reset without knowing the password:

Just still seems weird to have the password in plaintext on in a config file.

has to be somewhere, how else can an application connect? Look at WordPress, for example, you have to enter the password into the application so that the application can connect to the database. Otherwise, the database would have to have no password protection at all or you'd need a human to log in and enter the password every time a database connection was needed (which is normally thousands of times a minute.)

So, easy fix, the ca_stag2 was a staging DB that was not needed and was not current. The whole thing appears to have corrupted. So I simply "moved" that entire directory to /tmp (just in case I had to put it back) and then MySQL could fire up.

FLAMP >

@black3dynamite said in Setting Up a Standard MySQL or MariaDB Database for an Application:

@JaredBusch said in Setting Up a Standard MySQL or MariaDB Database for an Application:

I like my approach to setting this up.

Obviously, install MySQL/MariaDB first as noted above.

Then do the following. This all needs done in the same SSH session, but otherwise things are simple.

Choose once of these exports for your DB root password.

The first one is for you to specify, the second generates a random one and echo's it back to you.

# Specify your own password for MariaDB root user export DB_ROOT_PASS="somebigpasswordgoeshere" # Generate a random password for MariaDB root user export DB_ROOT_PASS="$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 30)" echo "This is your MariaDB root password: $DB_ROOT_PASS" Specify the application database name and application user name # Database user to use for application export DB_USER='yourusername' # Database name to use for application export DB_NAME='yourdatabasename' Generate or specify a random password for the database user # Specify your own password for the application's database user export DB_PASS="somebigpasswordgoeshere" # Generate a random password for the application's database user export DB_PASS="$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 30)" echo "This is your password for the application user: $DB_PASS" Then create the application database, use, and grant access. mysql -e "CREATE DATABASE $DB_NAME;" mysql -e "CREATE USER '$DB_USER'@'localhost' IDENTIFIED BY '$DB_PASS';" mysql -e "GRANT ALL ON $DB_NAME.* TO '$DB_USER'@'localhost';" mysql -e "FLUSH PRIVILEGES;" Finally, lock down the system without the interactive requirement of mysql_secure_installation # Secure MariaDB (this does what mysql_secure_installation performs without interaction) mysql -e "UPDATE mysql.user SET Password=PASSWORD('$DB_ROOT_PASS') WHERE User='root';" mysql -e "DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1');" mysql -e "DELETE FROM mysql.user WHERE User='';" # Beginning on some version of MariaDB after Fedora 29 was released, the test DB is no longer there by defualt. mysql -e "DROP DATABASE test;" mysql -e "FLUSH PRIVILEGES;"

Your approach makes it easier to use as part of a script.

It also generates random passwords, which I prefer.

@Dashrender said in Make an osTicket Database Backup:

Total DB Admin noob here - so bare with me.

Does this include the username/password setup for this DB? or does that need to be maintained separately?

i.e. you have to rebuild from this backup - do you just create a brand new SQL user and grant them rights to this DB upon import, then use that new account to give access to the app?

In typing out my question I kinda assume the answer is the second bit - you just create a new user and assign them rights.

Correct. The user and the database are separate things.

@magicmarker

Why dont they create one giant hazardous label to fit all the products, and make it generic as possible.

Like this product contains hazardous chemicals.

it is not like someone actual reads that small fine print.

Another problem solved...

@obsolesce I think that is what I had to do a couple years ago once. No idea why it started doing it and couldnt figure out any other way.

@Pete-S said in Need a web GUI interface to MySQL:

@jaredbusch said in Need a web GUI interface to MySQL:

@pete-s said in Need a web GUI interface to MySQL:

@jaredbusch said in Need a web GUI interface to MySQL:

@emad-r said in Need a web GUI interface to MySQL:

For admin stuff, most devs uses mysql workbench its 28 MB and has alot of functionality.

@pete-s said in Need a web GUI interface to MySQL:

If it doesn't have to be web based you could use MySQL Workbench - which I think is more capable than the web GUIs.

Overkill and slow.

It's not overkill if you're a DBA or developer.
And if you're smart you install it on the machine you do admin from and not on each server.
And you did ask for the best...

Actually, no I did not. Read the OP again. Don’t forget the title of the thread.

A fat client is almost always overkill and slow. But MySQL Workbench is a total piece of crap.

The web tools you are talking about also requires a web server and a php installation so they're not exactly "thin" but you want something simple on a LAMP server or similar. I get that.

MySQL Workbench has it's place too. It's to MySQL what SQL Developer and Enterprise Manager is to Oracle DB. I find it useful and use it almost daily.

MySQL Workbench has very little use to me as it is such a heavy handed client. Yes it works. No I do not like it.

For a client on Linux, I prefer Azure Data Studio actually. It is lightweight and lets me work without being in my way. It is based on the VSCode backend to my understanding. If it ever gets MySQL connectivity it will be perfect.

@scottalanmiller Yeah both of my webservers use mariadb for example

@bbigford said in osTicket: Basic Ticket Report of All Tickets with Subject:

Since there is no inner or outter join specified, inner join is obviously being used where 'join' is specified (outter join having to be explicitly defined where an outter join is needed). How come you explicitly specify 'inner join' at the bottom when you could just use 'join' again as your inner join?

Obviously join and inner join accomplish the same thing, just curious why one is not explicitly defined and the other is.

I expanded on something done by someone from the osTicket team. it was some weird stylistic choice that they made and I just followed.

@jaredbusch said in MariaDB on Fedora 27 Fails to Start from RocksDB Inclusion:

@scottalanmiller So as my systems update over the next 24 hours they are all going to break?

Hit us on update, no restart involved 😞

@fuznutz04 said in MySQL configuration best practices:

@emad-r

What is your practice for log rotation? For example, the error log. If that grows (obviously indicating other issues) , and needs to be rotated, what procedure do you use to rotate logs?

Currently the third party vendor uses this:

expire_logs_days = 10
max_binlog_size = 100M

In our MySQL instance.