I am trying to move my database from a Managed Digital Ocean MYSQL database to GCP Cloud SQL and I thought I'd give the Database Migration Service a try.
Note that I have already tried the One time mysql dump method and it
works fine. I just wanted to try out the Continuous method to minimize down time.
Before even creating the job and running, I try to "Test the job" but I get the following error:
zoho-tracker is the project name and destination-mysql-8 is the destination profile name. This is something else that confuses me, the button says "Go To Source" while the error string shows the destination profile name.
I have tried reading the docs as much as I could and I have checked the prerequisites too. Here are some points of information:
Source MYSQL version is 8.0.20 and destination value I am setting is 8.
The GTID Mode value that I checked using SHOW VARIABLES LIKE 'gtid_mode' is found to be ON.
The server_id value is 2(non zero).
All tables in the relevant DB are innoDB.
The user on the source has the following privileges: SELECT, EXECUTE, RELOAD, SHOW VIEW, REPLICATION CLIENT, REPLICATION SLAVE.
The user/pass/host combo has been verified many times and is correct.
The user was created with 'username'#'%' string and not 'username'#'localhost'.
The user was created with mysql_native_password plugin (although I have tried different users which use the caching_sha2 plugin too).
The connectivity method is IP allowlist and all connections while testing are allowed, so I don't think I need to add the destination IP to the allowlist.
The version_comment variable in the source has a value of 'Source Distribution' not 'Maria DB'.
Any pointers would be appreciated.
Related
I have one MySQL 5.6 running in production with a legacy root account that is used for years. As part of a hardening program, I wanted to remove this root account - make it available via another account not named root basically.
After creating another account named adminacc with full accesses on the DB, I deleted the account named root.
Right after this action, all (adminacc could still log in) my others accounts could not log in anymore receiving the below message
SQL State 28000 Error 1045: Access denied for user 'XXX'#'wathever' (using password: YES)
I granted the denied account full accesses on the DB - without success.
I finally recreated my root account (with the same previous password, not sure if relevant here) and my DB accounts went back.
How can it be there is a dependency between an account (would it be the initial root) and another in MySQL? Would it be because I created this other account while connected as root user? Or the other account is trying to query a view created by the root account? I believe not, just throwing thoughts trying to understand.
What I found the most weird in my senario is that the connection from the denied account was not completely denied. When testing the connection from a Windows odbcad32.exe utility, it succeedded! But whenever used in app context (running from the same windows host), it failed.
I did run a capture and here is the output (this is from the app context)
You can see the login actually happens well; few queries are executed properly (basically init statments at session opening like SET NAMES utf8 or SET SQL_AUTO_IS_NULL = 0).
Then the error is thrown when the user tries to execute a SELECT against one of the DB views.
Nota: I found no recommendation from MySQL docs to not delete the initial root account. Nothing describing such situation. Browsing a bit on the internet, I found this previous StackOverflow question but it remained unanswered.
As explained by Akina, this issue was tied to Stored Object Access Control in MySQL. Not only this applies to procedures, functions, triggers but views as well, read this
For stored routines (procedures and functions) and views, the object
definition can include an SQL SECURITY characteristic with a value of
DEFINER or INVOKER to specify whether the object executes in definer
or invoker context. If the definition omits the SQL SECURITY
characteristic, the default is definer context.
My errors actually appear whenever a view was called (and because all of the views were created via this root account and with the SQL SECURITY set to DEFINER - default behavior).
Making a lot of sense now. That being said, the MySQL error message could have been more descriptive on the actual issue!
I have an existing MySQL (version 5.7) instance hosted (managed) by Google Cloud SQL. I want to get a notification when someone is trying to connect my database with a bad username\password.
My idea was to look for it on the Google Stackrive logs, but it's not there.
There is an option to collect this information?
UPDATE 1:
I tried to connect the instance with gcloud but unfortunately, it's not working.
$ gcloud sql connect mydb
Whitelisting your IP for incoming connection for 5 minutes...done.
ERROR: (gcloud.sql.connect) It seems your client does not have ipv6 connectivity and the database instance does not have an ipv4 address. Please request an ipv4 address for this database instance.
It's because the database is accessible only inside the internal network. I searched for flags like --internal-ip but didn't find one.
However, I was guessing that it's not making any difference if I'll try to access the database from my DB editor (workbench). So I did it:
Searching for the query that #Christopher advised - but it's not there.
What I missed?
UPDATE 2:
Screenshot of my Stackdrive:
Even if I remove this (resource.labels.database_id="***") condition - the result is the same.
There is an option to collect this information?
One of the best options to collect information about who is trying to connect to your Google Cloud SQL instance with wrong credentials is Stackdriver Logging.
Before beginning
To reproduce this steps, I connected to the Cloud SQL instance using the gcloud command:
gcloud sql connect [CLOUD_SQL_INSTANCE]
I am not entirely sure if using the mysql command line something will change along the lines, but in case it does, you should only look for the new log message, and update the last boolean entry (from point 4 on).
How to collect this information from Stackdriver Logging
Go under Stackdriver → Logging section.
To get the information we are looking for, we will use advanced log queries. Advanced log queries are expressions that can specify a set of log entries from any number of logs. Advanced logs queries can be used in the Logs Viewer, the Logging API, or the gcloud command-line tool. They are a powerful tool to get information from logs.
Here you will find how to get and enable advanced log queries in your logs.
Advanced log queries are just boolean expressions that specify a subset of all the log entries in your project. To find out who has enter with wrong credentials into your Cloud SQL instance running MySQL, we will use the following queries:
resource.type="cloudsql_database"
resource.labels.database_id="[PROJECT_ID]:[CLOUD_SQL_INSTANCE]"
textPayload:"Access denied for user"
Where [PROJECT_ID] corresponds to your project ID and [CLOUD_SQL_INSTANCE] corresponds to the name of the Cloud SQL instance you would like to supervise.
If you notice, the last boolean expression corresponding to textPayload uses the : operator.
As described here by using the : operator we are looking for matches with any sub string in the log entry field, so every log that matches the string specified, which in this case is: "Access denied for user".
If now some user enters the wrong credentials, you should see a message like the following appear within your logs:
[TIMEFRAME][Note] Access denied for user 'USERNAME'#'[IP]' (using password: YES)
From here is a matter of using one of GCP products to send you a notification when a user enters the wrong credentials.
I hope it helps.
As said in the GCP documentation :
Cloud Shell doesn't currently support connecting to a Cloud SQL instance that has only a private IP address.
Context: Telephony system (Asterisk) using the MySQL C API to connect to the database to lookup the routing for a call as it comes in. The lookup involves connecting to the database, executing a query, then closing the connection.
Sometimes the very first call in the morning generates the following error:
Access denied for user 'asterisk'#'127.0.0.1' (using password: YES)
Normally this would mean the password was wrong, but that's obviously not the case here, since it uses the same user and password all the time for all the calls. It's as if the system has somehow "gone to sleep" or perhaps a file handle has become stale somewhere, so that the first attempt to the connect to the database fails, but the rest work fine. Also it only happens occasionally, so I'm unable to replicate it - very strange!
I'm using Asterisk 1.8.32 with MySQL 5.5 on Debian 8.7.
It's a bit of a headscratcher, so I would be grateful for any suggestions!
First of all it is very bad idea use 1.8.* tree at current moment becuase of security feature.
Move to 11.* fix this issue.
Also you can do following in my.cnf
interactive_timeout=
Set to any value more then 4 days(weekend)
Other option is reload mysql module by crontab every 3 hrs.
Best option(except upgrade) is move from mysql to res_odbc, which have keepalive option. res_config_mysql considering deprecated, so any new systems should use ODBC.
Deployed a new version of our app on heroku and migrated over database from previous free jawsdb instance. However now every time user signs up gives
(Mysql2::Error: INSERT command denied to user <username for instance
what have i missed
migrated using a dump and re-import using mysql command line. eye balled exported data and it seems to be there (user emails etc)
all config vars look ok (DATABASE_URL is mysql2...)
i can login to the database via the url
I have not had to grant access or anything like that before, anyone come across this?
thanks
Ben
My guess is they disabled your INSERT grant because you have reached your max Storage Capacity for your plan.
To validate this is a permissions problem, log into a MySQL prompt with the user the app is running as, and enter this query:
SHOW GRANTS;
It probably list many, but no INSERT.
See this link. As explained in given link, jawsdb preliminary plan does not give you permission to add a new database. You are provided with one schema with some random name and you have to work with that only.
Check your migration
e.g. Make sure the database name matches.
For me, I got the same error as OP when trying to migrate my data. This was a fresh account with only a 50kb'ish database; nowhere close to the free-plan 5mb limit.
In my SQL export statement, my local database name is being used, however the remote MySQL (ie JawsDB) service auto-generates a db name, which will obviously not be the same. Simply used find-replace to change the database name to match remote; everything works.
I'm trying to execute the command in the Windows console:
C:\SphinxSearch\bin\indexer --all --config C:\SphinxSearch\sphinx.conf
But I get an error:
ERROR: index 'indexname': sql_connect: Can't create TCP/IP socket
(10093) (DSN=mysql://root:*#localhost:3306/test).
A data source is mysql. Before the server restart everyone works fine.
How can I fix it?
I'm having the same error 10093. It's a windows error code by the way. In my case it occurs when trying to run the indexer through the system account via a scheduled task. If I'm running it directly as administrator, there's not a problem.
According to the site above:
Either your application hasn't called WSAStartup(), or WSAStartup() failed, or--possibly--you are accessing a socket which the current active task does not own (i.e. you're trying to share a socket between tasks).
In my case I'm thinking it might be the last one, some security problem due to user SYSTEM being used in my scheduled task. I was able to solve it by using my admin user instead: in the scheduled task, I set to use my local admin account with the option to "Run when user is logged on or not" and "Do not store password". I've also checked "Run with highest privileges". This seems to have done the trick as now my indexes are rotating on schedule.