How to modify MariaDB SQL Error Log plugin system variables? - mariadb

I just installed this plugin to monitor SQL errors:
https://mariadb.com/kb/en/sql-error-log-plugin/
but I can't for the life of me find anything on how to modify the default system variables for that error log plugin, and where.
Anyone?!

You can't modify error plugin log variables via SQL statements. They are either read-only and/or they need to be specified at startup (see source code).
So you have to pass these values either to mariadbd/mysqld or you have to specify these in your configuration file.
Example in /etc/my.cnf:
[server]
sql-error-log-filename=foo.log
sql-error-log-rotate=ON
restart server and check the values
MariaDB [test]> show variables like 'sql_error%';
+--------------------------+---------+
| Variable_name | Value |
+--------------------------+---------+
| sql_error_log_filename | foo.log |
| sql_error_log_rate | 1 |
| sql_error_log_rotate | ON |
| sql_error_log_rotations | 9 |
| sql_error_log_size_limit | 1000000 |
+--------------------------+---------+

Related

Openstack Keystone Install Issues

When trying to create Keystone:
openstack domain create --description "An Example Domain" example
I get this return error below:
Could not clean up: 'ClientManager' object has no attribute
'sdk_connection'
I am not sure what this is in reference to...
following the Doc here https://docs.openstack.org//keystone/wallaby/doc-keystone.pdf
This means that you aren't authenticated.
stack#ubuntu:~/devstack$ openstack domain create --description "An Example Domain" example
Missing value auth-url required for auth plugin password
Could not clean up: 'ClientManager' object has no attribute 'sdk_connection'
If you are using devstack you can just source userrc_early inside the devstack folder.
stack#ubuntu:~/devstack$ source userrc_early
stack#ubuntu:~/devstack$ openstack domain create --description "An Example Domain" example
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | An Example Domain |
| enabled | True |
| id | 1ddc2084930d492dbe39680cda5ef660 |
| name | example |
| options | {} |
| tags | [] |
+-------------+----------------------------------+

Flyway database migration tool info option not printing the version number

WE have flyway integrated with Redshift and we are using this as a simple java main program to run all our schema migrations. We also use the info command to print the current version of the database, However this command successfully runs or at least appears to run but does not print the version number.
We have version 4.2 of the flyway jar. What is that we may be missing? Thanks
To manually recreate what the info command line option does in java code you can copy what its implementation does (from the source):
MigrationInfoDumper.dumpToAsciiTable(flyway.info().all())
An example from the docs is shown below:
+-------------+------------------------+---------------------+---------+
| Version | Description | Installed on | State |
+-------------+------------------------+---------------------+---------+
| 1 | Initial structure | | Pending |
| 1.1 | Populate table | | Pending |
| 1.3 | And his brother | | Pending |
+-------------+------------------------+---------------------+---------+

How to restart ceilometer service

I changed pulling intervals in /etc/ceilometer/pipeline.yaml file from 600 to 60 and can't make the service to use new values. I restarted everything that relates to ceilometer in openstack-status command, but that did not work. Can somebody tell me the proper way how to do it?
I am using Openstack Liberty on Ubuntu 14.04 LTS
root#OS1:~# openstack service list
+----------------------------------+------------+---------------+
| ID | Name | Type |
+----------------------------------+------------+---------------+
| 056fcccaad5c4991a8a0da199ed1d737 | cinderv2 | volumev2 |
| 483a0cd1ba79430690a8960ae3d40222 | glance | image |
| 5c704fc9253e4c15895589eb19fab2ac | keystone | identity |
| 92bfcfb417314e80a43e6e7d4d21f99b | nova | compute |
| a7a3809d73674d3da3fbe8030b47055a | horizon | dashboard |
| c21b5e3c9d68417cb11df60d72f9bb58 | heat | orchestration |
| c7030edb082346328a715b00098b974a | neutron | network |
| d331f5360e2b4d3a854e7f47107a9421 | ec2 | ec2 |
| f0a22f827bed43dbbc43822abfc3e3e0 | ceilometer | metering |
+----------------------------------+------------+---------------+
root#OS11:~# openstack-status
.
.
.
== Ceilometer services ==
ceilometer-api: active
ceilometer-agent-central: active
ceilometer-agent-compute: inactive (disabled on boot)
ceilometer-collector: active
ceilometer-alarm-notifier: active
ceilometer-alarm-evaluator: active
ceilometer-agent-notification:active
.
.
.
Well, you need to restart ceilometer-agent-notification service because this service is responsible for transforming the data into samples in the ceilometer database.
Thus, systemctl restart ceilometer-agent-notification.service will help along with restarting other services.
Since ceilometer-agent-compute service is disabled, you just need to restart ceilometer-agent-central service on the node you have modified the config file.
sudo service ceilometer-agent-central restart
You might want to auto reload pipelines after you modify it, for that, you can set refresh_pipeline_cfg=True and a proper time for pipeline_polling_interval such as 120 seconds in /etc/ceilometer/ceilometer.conf.
Note, be careful when you enable auto reload, and only save pipeline config file after you are sure about the content is right (otherwise it might lose 1 polling period data)

flywaydb baseline baselineVersion parameter is being ignored

I am trying to impelment flywaydb in our process. In our env each client has their own instance of the DB.
I have a bash that loops through the clients to run migrate. So the command looks like
flyway -url=jdbc:jtds:sqlserver://localhost:1434/main_client_$ID migrate
This all works when all the clients start from the baseline. But as we add new customers their DB will reflect the newest code. Now we have older clients started with V1(and all the migration scripts to V2) and new clients with the latest DB V2.
I thought i could do something like :::
flyway baseline -url=jdbc:jtds:sqlserver://localhost:1434/main_client_3
--baselineVersion=2 --baselineDescription="Base 2 version"
but when i do it this way then call info i see something like :
+---------+-----------------------+---------------------+---------+
| Version | Description | Installed on | State |
+---------+-----------------------+---------------------+---------+
| 1 | << Flyway Baseline >> | 2015-06-08 22:07:54 | Success |
| 1.1 | update | | Pending |
| 1.2.0 | update | | Pending |
| 1.2.1 | update | | Pending |
+---------+-----------------------+---------------------+---------+
if i look in the DB i see the version value of schema_version set to 1.
if via the DB i force schema_version column value to 1.2.0 i see
+---------+-----------------------+---------------------+---------+
| Version | Description | Installed on | State |
+---------+-----------------------+---------------------+---------+
| 1 | Base version initial | | <Baseln |
| 1.1 | update | | <Baseln |
| 1.2.0 | << Flyway Baseline >> | 2015-06-08 22:07:54 | Success |
| 1.2.1 | update | | Pending |
+---------+-----------------------+---------------------+---------+
This is what i want.
But i can not figure out how to set the value via the baseline command
Thanks for any help
All parameters should be passed in with - not --

InnoDB tables exist in MySQL but says they do not exist after copying database to new server

I used mysqldump to export my database and then I imported it into MySQL on my other server. I can now see all my tables if I do "show tables" but I can't actually select from or describe any of them.
ERROR 1146 (42S02): Table 'mydatabase.user' doesn't exist
All of my tables are InnoDB. I saw one issue people had where they were using old_passwords, so I explicitly set that to 0 in my.cnf and I made sure all of the passwords in the mysql table were 41 hexadecimal digits as they should be for the new passwords.
The reason "show tables;" works is because mysqld will scan the database directory for .frm files only. As long as they exist, it sees a table definition.
If you imported the data into MySQL and this error message happens, the first thing I would immediately do is run this command: (BTW This is MySQL 5.1.45, but works in MySQL 5.x anyway)
mysql> show engines;
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance | NO | NO | NO |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
8 rows in set (0.00 sec)
If the server you imported the data into says InnoDB is disabled, then you have a big problem. Here is what you should do:
1) Drop all the Data from the New Import DB Server
2) Cleanup InnoDB Setup
3) run SHOW ENGINES; and make sure InnoDB is fully operational !!!
4) Reload the mysqldump into the new import server
Give it a Try !!!
I had this problem when I changed from a windows server to a Linux server.
Tables are files, and windows files are case insesitive, but linux files are case sensitive.
In my aplication, in the sql queries, some times I used uppercase tablenames and other times lowercase, so, sometimes I obtained the same result as you.
I my case it was SQLCA.DBParm parameter.
I used SQLCA.DBParm = "Databse = "sle_database.text"" but it must be
SQLCA.DBParm = "Database='" +sle_database.text+ "'"
Explain : you are going to combine three strings :
a) Database=' - "Database='"
b) (name of the database) - +sle_database.text+
c) ' - "'"

Resources