I am attempting to clone a database. I was able to previous clone it in the console, but now I want to create a small script to automate this and it fails with the following error message:
(gcloud.sql.instances.clone) [ERROR_RDBMS] unable to update the following flags: cloudsql.enable_password_validation
If I attempt to clone it in the console, I get the same error shown above.
I looked up the documentation and enable_password_validation does not seem to be in the list of supported flags, which would explain why it can't update it.
If I run gcloud sql instances describe my-instance, I don't see the flag in question.
But running on the source instance:
SELECT * FROM pg_settings
yields this row in particular:
name
setting
unit
category
short_desc
extra_desc
context
vartype
source
min_val
max_val
enumvals
boot_val
reset_val
sourcefile
sourceline
pending_restart
cloudsql.enable_password_validation
off
NULL
Customized Options
Sets whether to enable Cloud SQL password validation.
NULL
superuser
bool
configuration file
NULL
NULL
NULL
on
off
/pgsql/data/postgresql.auto.conf
3
False
Any advice on how to solve this?
There is currently an ongoing issue with password validation in Cloud SQL Postgres instances. The issue involves the exact flag that is giving you problems cloudsql.enable_password_validation:
Diagnosis: Affected postgres instances from a recent release have the following flag set and are unable to remove or disable this flag: cloudsql.enable_password_validation=on. This flag does not appear in Cloud Console, and attempting to disable flag via gcloud returns error where the flag is not recognized or supported. Password validation occurs on every new client connection but is limited to 50 QPS, and thus higher rates will return errors.
When did this issue start occurring? Have you also attempted to clone the database since then? This is due to the issue receiving several updates. If you continue experiencing issues, you could open a support case with GCP as the status page recommends.
EDIT (2/24/2022)
I wanted to update this answer. The issue seems to be resolved as shown in the status page of Google Cloud:
The issue with Cloud SQL has been resolved for all affected instances as of Tuesday, 2022-02-22 14:30 US/Pacific. We thank you for your patience while we worked on resolving the issue.
If you still see this error, you can update the question confirming that it was not resolved as part of the outage resolution.
Related
I am receiving an error when updating my report. This is a report that has 2 sources, one in SQL Server and one in MariaDB. I have no problem assigning these two sources, however when I try to automate the report and manually update it gives me the following error:
enter image description here
I have tried to check and clean the file sources but it doesn't work.
We have suddenly started experiencing an error when using the DialogFlow "restore agent" API. The call is failing with the error:
400 com.google.apps.framework.request.BadRequestException: Invalid
agent zip. Missing required json file agent.json
Oddly, it only seems to happen for newly created DialogFlow agents, but not for older/existing ones. We are using this API so that we can programmatically create a custom agent using our own intents/entities. This code has been working for about the past two years, with no changes on our side. We are using the official DialogFlow client library for Python. We have been on version 0.2.0, and I tried updating to the latest (0.8.0) but there was no change.
I tried changing our code to include the agent.json file (by using the "export agent" API and getting the agent.json file from there). In that case, I no longer get the above error and the restore appears to succeed. However, the agent then seems to be corrupt in some way. When trying to click on any intent -- or various other operations in the DialogFlow console -- I get the error:
Failed to get Training Phrases Errorid=xxx
(where xxx seems to be a UUID that changes each time)
Trying to export the agent in that state also displays an error:
Error downloading agent
Occasionally, even including the agent.json as above, the restore will still fail but return the error:
500 Internal error encountered.
I appreciate any ideas on how we can get this working again. Thanks!
After a lot of trial and error I found the solution. Here it is in case anyone else runs into this. Something must have changed recently in how DialogFlow processes the zip upload during the "restore agent" operation --
1) The agent.json file is now required in the zip file, where before it was optional
2) We found some of the "id" elements in our _usersays files for various intents were not valid UUIDs. Previously this did not cause any error, but now the agent winds up in an invalid state ("Failed to get Training Phrases" error, etc as mentioned above).
Easy way to fix is to export one of the existing agents and copy it's agent.json and package.json into your current directory before uploading.
agent.json is now required by dialogflow.
I created an instance with Debian 9 and was following the instructions on Google's site here. I have done this before successfully. All was going fine, but now when I do this part:
DISPLAY= /opt/google/chrome-remote-desktop/start-host \
--code="4/xxxxxxxxxxxxxxxxxxxxxxxx" \
--redirect-url="https://remotedesktop.google.com/_/oauthredirect" \
--name=
I get the error
Adding user newuser_gmail_com to group chrome-remote-desktop
ERROR:Failed to access chrome-remote-desktop group. Is the user a
member?
Can anyone help me out here? I notice that when I did this previously, the username create was not newuser_gmail_com, but rather simply newuser. Any suggestions you have would be much appreciated. Many thanks!
I found the answer, but this raises a possible bug for the Google Cloud team. The bug occurs if I add enable-oslogin = TRUE as a metadata. This causes the chrome-remote-desktop to fail.
When a user is added to a group (chrome-remote-desktop in this case), the change is not reflected in existing sessions until the user logs out and back in. To work around this limitation, Chrome Remote Desktop attempts to use sg to access the new group from the existing session. It looks like this isn't working for some reason on this system (apparently OS Login related?), so starting the host fails.
It should be sufficient to log out and back in. Once logged back in, very that the output of groups contains chrome-remote-desktop, then try running the headless setup flow again. (Make sure you generate a new command, as the --code argument is one-time-use only.)
I'm trying to migrate and synchronize a PostgreSQL database using AWS DMS and I'm getting the following error.
Last Error Task error notification received from subtask 0, thread 0
[reptask/replicationtask.c:2673] [1020101] When working with Configured Slotname, user must
specify LSN; Error executing source loop; Stream component failed at subtask 0, component
st_0_D27UO7SI6SIKOSZ4V6RH4PPTZQ ; Stream component 'st_0_D27UO7SI6SIKOSZ4V6RH4PPTZQ'
terminated [reptask/replicationtask.c:2680] [1020101] Stop Reason FATAL_ERROR Error Level FATAL
I already created a replication slot and configured its name in the source endpoint.
DMS Engine version: 3.1.4
Does anyone knows anything that could help me?
Luan -
I experienced the same issue - I was trying to replicate data from Postgres to an S3 bucket.I would check two things - your version of Postgres and the DMS version being used.
I downgraded my RDS postgres version to 9.6 and my DMS version to 2.4.5 to get replication working.
You can find more details here -
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html
I wanted to try the newer versions of DMS (3.1.4 and 3.3.0[beta]) as it has parquet support but I have gotten the same errors you mentioned above.
Hope this helps.
It appears AWS expects you to use the pglogical extension rather than test_decoding. You have to:
add pglogical to shared_preload_libraries in parameter options
reboot
CREATE EXTENSION pglogical;
On dms 3.4.2 and postgres 12.3 without the slotName= setting DMS created the slot for itself. Also make sure you exclude the pglogical schema from the migration task as it has unsupported data types.
P.S. When DMS hits resource limits it silently fails. After resolving the LSN errors, I continued to get failures of the type Last Error Task 'psql2es' was suspended due to 6 successive unexpected failures Stop Reason FATAL_ERROR Error Level FATAL without any errors in the logs. I resolved this issue using the Advanced task settings > Full load tuning settings and tuning the parameters downward.
Rolling update for an instance group fails with "Invalid Fingerprint" error message at console. Earlier rollouts had no issues but recently started seeing this error and updates are failing, even a times Instance Group section of console is going unresponsive.
Already tried :
Creating New Image and using it in a new Template for rolling out update in instance group
Appreciate any clues or help.
Thanks
When trying to roll-out an update to my instance group with the "ROLLING RESTART/REPLACE" button, I got a “Invalid Fingerprint” error message in the Notification. This issue might also be caused by the "ROLLING UPDATE" button. (capital letters are shown at the source GCE interface)
My instance group size was set to 1 instance, and I was getting the error:
"Invalid fingerprint"
To solve the problem, I changed the Instance Group size from 1 to 2, and then rolled the update.
After the update was done - I change the group size back to 1.
For documentation purposes, the error looks like this:
Edit the Instance Group (set number of instances) by clicking the edit button:
.. and update the number of instances:
Currently, our Internal Compute Engine team working on the issue, The current workaround is to use the gcloud command which should also fix the issue on the Cloud Console afterwards. you can do a rolling replace using:
gcloud beta compute instance-groups managed rolling-action replace [instance group]
You can find the details of the command at this link. Also, you can keep an eye for complete resolution of the issue at this public issue tracker link where other users field a defect report. I must also mention that Updating Managed Instance Group is a beta feature as of now.