CLOUD SQL VERSION & DB ENGINE: Currently our CLOUD MYSQL Version is 5.6.21 n DB ENGINE is INNODB
1. Create User In Mysql
Create User 'USERNAME' # 'HOSTNAME' Identified By 'PASSWORD';
But This User Is Not Permanently Stored In mysql.user Table. This User Getting removed In The Table If Any Issue Comes In Script Side Or Server Restarts...and also sometimes, created user password gets empty.
2.Likewise Grant Execute Permission For Procedure Also Not Working Properly.
Grant Execute On Procedure Schemaname . Spname To 'USERNAME'#'%';
This Execute Permission Works For Some Time,But The Privileges Immediately Disappears For The Granted User.
Other Solutons We Tried Are:
1.Flush Tables-After Creating User
2.Flush Privilges- After Giving Any Grant Access/Revoke Access
But These 2 Solutions Are Also Not Working In Google Cloud Sql, Still Issue Remains Same.
But This Issue We Dont Have In Local Mysql Version, It Is Reproducible Only On Google Cloud Sql.
We are Struck With This Issue In Our Front End App.
Anyone knows how To resolve This Issue In Google Cloud Sql...
I'm not able to reproduce the fact that a creating a user doesn't survive a Cloud SQL instances.
Here is how I tested (I replaces some sensitive information with (edited)).
First I connect to an existing instance and create a user called xxx and checked that it shows up in the mysql.user table.
$ mysql -uroot -proot -h (edited)
mysql> SELECT host,user,password FROM mysql.user;
+-----------+------+-------------------------------------------+
| host | user | password |
+-----------+------+-------------------------------------------+
| localhost | root | |
| 127.0.0.1 | root | |
| ::1 | root | |
| localhost | | |
| % | root | *81F5E21E35407D884A6CD4A731AEBFB6AF209E1B |
+-----------+------+-------------------------------------------+
5 rows in set (0.07 sec)
mysql> CREATE USER xxx#'%' IDENTIFIED BY 'xxx';
Query OK, 0 rows affected (0.61 sec)
mysql> SELECT host,user,password FROM mysql.user;
+-----------+------+-------------------------------------------+
| host | user | password |
+-----------+------+-------------------------------------------+
| localhost | root | |
| 127.0.0.1 | root | |
| ::1 | root | |
| localhost | | |
| % | root | *81F5E21E35407D884A6CD4A731AEBFB6AF209E1B |
| % | xxx | *3D56A309CD04FA2EEF181462E59011F075C89548 |
+-----------+------+-------------------------------------------+
6 rows in set (0.06 sec)
mysql> Bye
Then I restart the Cloud SQL instances.
$ gcloud sql instances restart (edited) --project (edited)
Restarting Cloud SQL instance...done.
Restarted [https://www.googleapis.com/sql/v1beta3/projects/(edited)/instances/(edited)].
$
Then I connected again and check the mysql.user tables.
$ mysql -uroot -proot -h (edited)
mysql> SELECT host,user,password FROM mysql.user;
+-----------+------+-------------------------------------------+
| host | user | password |
+-----------+------+-------------------------------------------+
| localhost | root | |
| 127.0.0.1 | root | |
| ::1 | root | |
| localhost | | |
| % | root | *81F5E21E35407D884A6CD4A731AEBFB6AF209E1B |
| % | xxx | *3D56A309CD04FA2EEF181462E59011F075C89548 |
+-----------+------+-------------------------------------------+
6 rows in set (0.07 sec)
mysql> Bye
$
Related
I'm trying to upgrade a postgres server from 10 12, and am having problems with the encodings. I'm following what I believe to be established recipes.
Behold:
postgres#serverbot:~$ psql -l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-------------+----------+-----------+---------+-------+-----------------------
postgres | postgres | SQL_ASCII | C | C |
template0 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | SQL_ASCII | C | C | postgres=CTc/postgres+
| | | | | =c/postgres
thingsboard | postgres | SQL_ASCII | C | C | =Tc/postgres +
| | | | | postgres=CTc/postgres+
| | | | | nagios=c/postgres
(4 rows)
Notice the encodings on the 10 database. Time to create the database for 12.
postgres#serverbot:~$ sudo service postgresql stop
postgres#serverbot:~$ /usr/lib/postgresql/12/bin/initdb -E SQL_ASCII --locale=C -D /var/lib/postgresql/12/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".
Data page checksums are disabled.
creating directory /var/lib/postgresql/12/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... America/New_York
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
Success. You can now start the database server using:
/usr/lib/postgresql/12/bin/pg_ctl -D /var/lib/postgresql/12/data -l logfile start
Excellent! Let's fire up the new server.
postgres#serverbot:~$ /usr/lib/postgresql/12/bin/pg_ctl -D /var/lib/postgresql/12/data -l logfile start
waiting for server to start.... done
server started
And verify the encodings...
postgres#serverbot:~$ psql -l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+-----------+---------+-------+-----------------------
postgres | postgres | SQL_ASCII | C | C |
template0 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
(3 rows)
Everything matches... time to upgrade!
postgres#serverbot:~$ /usr/lib/postgresql/12/bin/pg_upgrade \
--old-datadir=/var/lib/postgresql/10/main \
--new-datadir=/var/lib/postgresql/12/main \
--old-bindir=/usr/lib/postgresql/10/bin \
--new-bindir=/usr/lib/postgresql/12/bin \
--old-options '-c config_file=/etc/postgresql/10/main/postgresql.conf' \
--new-options '-c config_file=/etc/postgresql/12/main/postgresql.conf' \
--link --check
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns ok
encodings for database "postgres" do not match: old "SQL_ASCII", new "UTF8"
Failure, exiting
postgres#serverbot:~$
Doh!
What is wrong here? I assert that the encodings do match, and I'm stuck.
Can anyone offer any advice?
What I see is:
postgres#serverbot:~$ /usr/lib/postgresql/12/bin/pg_ctl -D /var/lib/postgresql/12/data -l logfile start
waiting for server to start.... done
server started
and then:
postgres#serverbot:~$ /usr/lib/postgresql/12/bin/pg_upgrade \
--old-datadir=/var/lib/postgresql/10/main \
--new-datadir=/var/lib/postgresql/12/main \
[...]
Note the $PGDATA directories. The database cluster you did the initdb for is different from the one you are doing the pg_upgrade to.
UPDATE. Since you seem to be using a Debian based OS and it's Postgres packaging, it might work better to stick with the packaging tools:
sudo pg_createcluster --locale=C 12 ascii
Creating new PostgreSQL cluster 12/ascii ...
/usr/lib/postgresql/12/bin/initdb -D /var/lib/postgresql/12/ascii --auth-local peer --auth-host md5 --locale C
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/12/ascii ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... America/Los_Angeles
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctlcluster 12 ascii start
Ver Cluster Port Status Owner Data directory Log file
12 ascii 5434 down postgres /var/lib/postgresql/12/ascii /var/log/postgresql/postgresql-12-ascii.log
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+-----------+---------+-------+-----------------------
postgres | postgres | SQL_ASCII | C | C |
template0 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
(3 rows)
Also I would use pg_upgradecluster, see here for more information. This keeps everything in the same system.
After performing a fail over, I had the previous Primary down, and the old standby became the Primary, as expected.
$ repmgr -f /etc/repmgr.conf cluster show --compact
ID | Name | Role | Status | Upstream | Location | Prio. | TLI
----+-----------------+---------+-----------+----------+----------+-------+-----
1 | server1 | primary | - failed | | default | 100 | ?
2 | server2 | primary | * running | | default | 100 | 2
3 | PG-Node-Witness | witness | * running | server2 | default | 0 | 1
I would like to make the old Primary join the cluster as a standby.
I gather the rejoin command should do that.
However, when I try to rejoin it, to be the new standby, I get this (I run this on the old Primary which is down ):
repmgr -f /etc/repmgr.conf -d 'host=10.9.7.97 user=repmgr dbname=repmgr' node rejoin
--where 10.9.7.97 is the ip of node I am running from.
I get this error:
$ repmgr -f /etc/repmgr.conf -d 'host=10.97.7.97 user=repmgr dbname=repmgr' node rejoin --verbose -
NOTICE: using provided configuration file "/etc/repmgr.conf"
ERROR: connection to database failed
DETAIL:
could not connect to server: Connection refused
Is the server running on host "10.97.7.97" and accepting
TCP/IP connections on port 5432?
Of course postgres is down on 10.9.7.97 - the old primary.
If I start it however, it starts as another primary:
$ repmgr -f /etc/repmgr.conf cluster show --compact
ID | Name | Role | Status | Upstream | Location | Prio. | TLI
----+-----------------+---------+-----------+----------+----------+-------+-----
1 | server1 | primary | ! running | | default | 100 | 1
2 | server2 | primary | * running | | default | 100 | 2
3 | PG-Node-Witness | witness | * running | server2 | default | 0 | 1
so what is the way to make the old primary the new standby...?
Thanks
Apparently the
-d 'host=
in the rejoin command, should specify the current Primary (previous standby).
I want to flush this DB so that the old owner doesn't exist anymore and I want to be the superuser.
I am using an ex-colleagues laptop ( mac )
PostgreSQL ( psql ) was installed via Homebrew ( 9.6 ) which I have removed as I required ( 9.5 ).
A few "perhaps" issues I've noticed:
psql9.5 is now installed and when I attempt to login I receive the following FATAL: role "MY NAME" does not exist
eventually login and when I "\l" I see the following:
DB_NAME-> \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+--------------+----------+-------------+-------------+-------------------------------
DB_NAME | DB_NAME | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 |
postgres | EX COLLEAGUE | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 |
template0 | EX COLLEAGUE | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | =c/EX COLLEAGUE +
| | | | | EX COLLEAGUE=CTc/EX COLLEAGUE
template1 | EX COLLEAGUE | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | =c/EX COLLEAGUE +
| | | | | EX COLLEAGUE=CTc/EX COLLEAGUE
when I run:
DB_NAME=> \du
List of roles
Role name | Attributes | Member of
--------------+------------------------------------------------------------+-----------
DB_NAME | Create DB | {}
EX COLLEAGUE | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
I can't create new Roles.
I might be over-exaggerating the severity of this - but I have no idea what to do.
I have looked at old resources and maybe I was searching incorrectly but I found no help.
Solved - had to re-install my Mac OS but was hoping for a less time consuming option
I'm attempting to run a Debian VM locally with vagrant. I'm using php 5.5 with apache and postgresql 9.1. Randomly my Symfony app seems to not be able to make a connection or something because i'll get an exception thrown saying that it couldn't find my table. I'll refresh the page a couple of times and then it'll find it and display the data. I don't know enough about server admin to debug this myself. Is there a connection timeout setting i can set somewhere that may alleviate this? or can you suggest another idea to determine/fix the problem?
The connection settings Symfony is using
database_driver: pdo_pgsql
database_host: 127.0.0.1
database_port: 5432
database_name: appDB
database_user: root
database_password: root
My postgres database structure
List of relations
Schema | Name | Type | Owner
--------+--------------------+----------+-------
public | migration_versions | table | root
public | users | table | root
public | users_id_seq | sequence | root
(3 rows)
My postgres permissions
Schema | Name | Type | Access privileges | Column access privileges
--------+--------------------+----------+-------------------+--------------------------
public | migration_versions | table | root=arwdDxt/root |
public | users | table | root=arwdDxt/root+|
| | | =arwdDxt/root |
public | users_id_seq | sequence | root=rwU/root +|
| | | =rwU/root |
(3 rows)
This question already has answers here:
In psql, why do some commands have no effect?
(2 answers)
Closed 2 years ago.
I am new to PostgreSQL and I try to get my head around it. I am familiar to db's and MySQL.
I am trying to delete database, which I created since psql seems to ignore the changes I try to push through Django.
When I execute \l I get the following response:
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
------------------+--------+----------+-------------+-------------+-------------------
postgres | neurix | UTF8 | en_AU.UTF-8 | en_AU.UTF-8 |
test_db | neurix | UTF8 | en_AU.UTF-8 | en_AU.UTF-8 |
template0 | neurix | UTF8 | en_AU.UTF-8 | en_AU.UTF-8 | =c/neurix +
| | | | | neurix=CTc/neurix
template1 | neurix | UTF8 | en_AU.UTF-8 | en_AU.UTF-8 | =c/neurix +
| | | | | neurix=CTc/neurix
template_postgis | neurix | UTF8 | en_AU.UTF-8 | en_AU.UTF-8 |
(5 rows)
Now I wan to drop the database "test_db" with
DROP DATABASE test_db
but when I execute \l afterwards, the table is still there and the overview looks like about.
Did you type a ; after the DROP DATABASE test_db? Did PostgreSQL print a response to your command?
I had a similar issue when working on a Rails 6 application in Ubuntu 20.04 with PostgreSQL as my database.
When I run the command:
DROP DATABASE my-db;
The database is dropped successfully, however, the schema for the database is still left.
So when I run the command:
CREATE DATABASE my-db;
And I check the tables in the newly created database, I realized they still contained the same tables as the previously deleted database, even though I have not run any migration.
Here's how I fixed it:
Instead of running the command:
DROP DATABASE my-db;
run the command:
DROP DATABASE IF EXISTS my-db;
This deletes the database and it's corresponding schema.
That's all.
I hope this helps